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0. Introduction z> i 

This report details the progress made in 1994 on the NASA/JSC 
NASA Research Announcement entitled "New Technologies For Space 
Avionics", contract number NAS 9-18873. This Document is divided 
into 4 volumes. The first volume details the general problem 
addressed by this effort and discusses the work in developing 
processes to address the technical problems. Volume 2 represents 
the report of the Test and Evaluation effort of the prototype Reaction 
Jet Drive controller. Volume 3 consists of a document which describes 
the design of the analog and digital portions of the controller that is 
the RJD prototype. Volume 4 is a report on the progress made in 
developing a mathematical model of the life cycle of a Pilot Operated 


f 7 ° 

< u5 P 


Valve. 


0.1 Accomplishments 

We have successfully met the goals that we set out in our proposal 
for this NRA activity. We have successfully fabricated a second 
prototype Reaction Jet Drive Controller with enhanced functionality, 
tested and demonstrated it's functionality in the Controls 
Development Laboratory at Johnson Space Center, and derived 
Avionics Subsystem architectural concepts and directions for future 
activities. Additionally, we have developed a mathematical model of 
the behavior of a pilot operated solenoid valve and demonstrated 
how this model successfully depicts the operation of the real valves. 
A report of these activities follows. 


0.2 Conclusions and Acknowledgemen ts 

As is detailed in some of the following report, much of this effort was 
directed at developing a better model of engineering process. 

Integral to this effort is the close cooperation of the members of 
many different organizations. As mentioned in the 1993 final report, 
this task really focused on a new paradigm of engineering design, 
that of cross-organizational teams. Therefore, it is appropriate to 
acknowledge and thank the very pro-active participation of Don 
Brown and Rick Loffi of the NASA/JSC EG technical staff, Wayne 
McCandless, Debra Hurdelbrink, and Lydia Wenglar of the Lockheed 
Engineering and Sciences Company. 



■1.0 The Rapid Prototyping o f Guidance Navigation and Control 
Systems 

1.1 The Problem 

This project has addressed the issues associated with the 
identification of requirements in the context of developing a 
prototype of a replacement controller for the Reaction Jet Drive (RJD) 
of a launch vehicle. The central problem addressed by this 
development effort, the successful definition of requirements, is one 
of critical importance to engineering organizations, be they in 
Government or private industry. We spent extensive effort last year 
in discussing this problem and the interested reader is referred to 
last year's (1993) report for further elaboration. 

1.2 The Process 

As is noted in last year's report, there are many approaches to 
address this problem. This effort used the concept of rapid 
prototyping to allow experimentation with requirements as the 
primary vehicle for identifying which requirements are, in fact, 
critical. This process only works well when the traditional customer- 
contractor boundaries are ignored and everyone becomes part of the 
design team. We feel we have illustrated this by instituting a design 
effort which utilized electronic communications, either e-mail or file 
transfer, and telephone conferences extensively among a team which 
was physically located in separate parts of the country and 
organizationally separated by company and Government boundaries. 
Additionally, we used NASA facilities to exercise the prototype while 
monitoring and debugging using the resources provided by the 
Internet network. 

This effort has been an example of a collaborative iterative process 
which is oriented towards providing the maximum return on 
investment. This process should presage the NASA development 
process of the future wherein requirements are poorly defined and 
understood at the beginning and it is only through an iterative 
process, with hands-on exposure to prototypes, that the real 
requirements are understood and captured. In addition, and of 
critical importance to NASA programs, by avoiding the normal 
process which typically involves an early technology freeze (in a 
mistaken attempt to contain risk), NASA can ride the technology 
curve provided by the commercial marketplace. Thus, for example, 
the 1994 prototype is based on a Xilinx 4000 series FPGA which 
represents technology that was too risky for the 1993 prototype. 
However, by building with iteration in mind and leveraging off the 



past experience, it was still possible to design and fabricate the 199 
prototype in under four months. Through this process, including the 
test and evaluation performed in NASA laboratory facilities, the 
design team has attempted to ensure that there are no "surprises" 
which seem to plague a procurement which follows normal NASA 
procurement channels. 

It is important to stress that this effort is merely an exploration of 
the requirements that pertain to the RJD controller, the prototypes 
are merely prototypes, and not predecessors of a production 
controller (For instance, it is to be anticipated, as noted below, that 
extensive development work will need to be undertaken to produce 
a new RJD controller that is capable of being qualified as Flight 
Hardware). Much of this effort, oriented towards Avionics 
Architectures, explored concepts about Vehicle Health Mangement 
which can be used to design avionics architectures for future, or 
upgraded, vehicles which offer greater system availability (and, 
consequently, greater opportunities for successful missions) than 
those used as the basis of current designs. Furthermore, although the 
RJD is merely a sample problem, the prototype which has been 
fabricated does address several issues associated with RCS systems. 
We have developed a prototype which is not only fail safe and fault 
tolerant, it is capable of fault detection, isolation, and recovery. 

Future versions will be capable of predicting the impending failures 
of POV solenoids. Additionally, this prototype has pioneered issues 
associated with the use of a new, digital interface based on the Mil- 
STD-1553B data bus. Future iterations of the prototype will address 
the issue of a redundant digital interface. The prototype has been 
deliberately constructed to explore these concepts while a real effort 
has been made to maintain the flexibilty to adapt the controler 
concepts to existing, or new, vehicle requirements as they become 
better defined. 

1.3 Future Activities 

In this section, we discuss some of the activiites which should be 
undertaken to further the development of the new Reaction Jet Drive 
controller, if a decision is made to produce a new piece of Flight 
Hardware. 

L characterize the env ironment 

Further development of the RJD controller prototype will require the 
further refining of the current, "captured" set of requirements. One 
area which needs particular attention is that of the operational 
environment to which the RJD controller will be subjected. The 
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categorized as those derived from the platform, or vehicle, and those 
that are derived from the nature of the technology which provides 
the supporting infrastructure, 

aa. vehic le environment 

The vehicle environment imposes restraints on the RJD design due to 
such factors as allowable volume, weight, and power consumption, 
vibration and radiation tolerance. As the prototype life cycle evolves 
and the fabricated prototypes approach Flight Hardware quality, the 
prototypes must conform to the requirements of a characterized 
platform. To avoid unexpected performance in the ultimate 
controller, it is important to develop a set of requirements for the 
prototype early in the life cycle and use experience with the 
prototypes in laboratory and experimental flight trials to refine these 
requirements. 


ab. technology failure modes 

The current prototype RJD controller has been designed and 
fabricated to respond to a given model of the failure modes 
associated with reaction jets. The validity of the underlying 
assumptions about these failure modes must be verified and 
extended to include as comprehensive set as possible. In this way, 
the RJD controller will, ultimately, be capable of addressing the 
identified modes. For instance, as detailed elsewhere in this Final 
Report, the current instantiation of the prototype RJD controller was 
designed to detect a failure of a solenoid due to a breakdown of the 
windings of the solenoid. In the course of the development of the 
mathematical model describing the physics of this phenomena, it was 
deteremined that this is a very unlikely occurrence, and, in fact, the 
most commonly observed solenoid failure is due to contamination. A 
careful study of the potential failure modes of the major components 
of the RCS subsystem is clearly a future activity. 

II. Packaging Technology 

The current prototype is not designed to address the size, weight and 
power requirements of a space vehicle. As it is configured, the digital 
and analog components are mounted on separate boards which are 
configured to allow maximum accessibility for laboratory equipment. 
Before such a design could be readied for flight, a re-design of the 
layout of components must be performed. The analog board contains 



the A/D's, op amps, filters, passive components, and all the switches 
necessary to control one reaction jet. All these components can be 
mounted on one standard 6U VME multi-layer printed circuit board. 
Use of this standard form factor will allow one VME card cage to act 
as a reaction jet subsystem controlling multiple jets - the energizing 
signals for each individual jet is housed in a single analog 6u card 
while the entire digital section (which can control multiple jets), with 
its redundant interface to the Flight Critical data bus, can be placed 
in a single additional card. 


111. Architecture Studies 

The transition from an analog interface to the Flight Control System 
to a digital one is more complex than merely changing the physical 
connection between the subsystems. Also important for consideration 
are the associated architectural performance issues such as bus- 
loading capacities and overall system latencies. These issues can be 
addressed by the construction of a simulation using a variety of 
commercially available tools, backed up and verified by detailed 
testing of prototypes in a laboratory setting. A key activity would be 
to establish the requirements for a RJD controller to fit into an 
Avionics subsystem which is architected based on the use of a digital 
bus such as the 1553. 


iv. Interface Development 

Key to the development of the new RJD controller has been the 
notion of utilizing a redundant digital interface based on the Mil- 
STD-1553B bus. The current instantiation of the controller has a 
single 1553 interface. For a vehicle, where safety of flight and 
reaction jet availability become critical, flight critical data will be 
carried on a redundant bus structure. Although redundant bus 
interfaces, capable of voting between several asynchronous input 
data streams, have been designed on paper (most notably by both 
Martin Marietta Astronautics and Lockheed Sanders), these 
interfaces have yet to be fabricated and characterized. This is an 
activity which will most likely be essential before a RJD controller 
can be flight qualified. 


v. Design Issues 


As described more fully in the Design Details in the attached 
Appendix 3, the actual power routing was achieved by using 
IR6220's in an elaborate tree configuration to improve redundancy. 
The IR6220's are a MOSFET and high-side driver circuit built into a 
single device. Alternate circuits have been considered where discrete 
MOSFETS and high-side driver devices are used. Also, there is 
another family of devices called electronic circuit breakers that may 
also be considered as candidate devices for routing of the energizing 
signals. These other candidate circuits need to be more fully 
characterized for comparison against the performance of the 
IR6220's. 
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1.0 Introduction 


This report documents the testing that was performed on both of the reaction jet driver 
(RJD) prototypes which were designed and built by Lockheed Sanders. The first version 
of the RJD, which will be referred to as prototype 1 throughout this report, was tested as 
part of the concurrent engineering process to iron out the requirements and any existing 
bugs as the second generation was being developed. The second prototype, which will be 
referred to as prototype 2, was tested to evaluate the performance of the RJD. 

The fundamental objectives of the test and evaluation program were to evaluate the 
suitability of Sanders' concept for an RJD in a shuttle upgrade application and as part of a 
next generation vehicle. These objectives included testing the tools, resources and 
procedures used as part of Sanders' concurrent engineering process. Also included in the 
objectives was determining the design trade-offs associated with a transition from analog to 
digital based electronics with emphasis placed on flight control system integration of a 
MIL- 1553 device. Some preliminary end of useful life signature indications for solenoid 
operated valves typically used in aerospace propulsion applications were collected, which 
allowed the comparison of a multi-stage pilot-operated valve with that of a direct acting 
valve. 

The four test sets performed on each prototype included basic functionality tests, bum 
duration and skew time tests, failure mode tests, and alternate load tests. The functionality 
tests were run to determine if the prototypes functioned as per the requirements outlined in 
the Reaction Jet Driver Digital Design Document. All tests met the requirements except 
where noted in section 3.1. The firing duration and skew time tests were run to verify the 
start time and duration in which a solenoid was activated. The results showed that these 
times matched the commanded times. The failure mode tests were run to verify the 
requirements in the design document. Again, all tests were successful and the results are 
outlined in section 3.3. 

In addition to testing the prototypes, the prototypes were used as a tool in testing a Marotta 
direct acting valve and two Marquardt pilot operated valves. When used, these valves 
replaced the load banks in the test configuration. Since the prototype was designed for 
controlling the direct acting valves, these tests provided some useful data which could be 
used later in defining valve characteristics and solenoid end of useful life. 

The following sections describe the test configuration, equipment, procedures, and results. 
Section 5 describes a parallel study that was performed as the tests were being run. That 
study consisted of RJD analysis performed with the FEAT (Failure Environment Analysis 
Tool) model. 
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2.0 


Test Configuration 


2. 1 Prototype 1 Configuration 

Prototype 1 and prototype 2 had slightly different test configurations. Prototype 1 required 
two PCs because Xilinx development work was being done on one PC while 1553 
development work was being done in parallel on the other PC. Figure 1 shows a diagram 
of the prototype 1 test configuration. A 386 PC was used for the 1553 interface instead of 
a 486 because equipment in the laboratory was limited. 

The RJD required a single 28 Volt power supply. Although the prototype had a circuit 
breaker installed to prevent damage to the prototype from high currents, the current limit 
was set to 3.0 Amps on the power supply. The power supply is connected to the RJD 
through a simple on/off switching box. Another precaution was that the digital and analog 
sides of the prototype were never connected or disconnected while the unit was powered 
up. This was recommended by Sanders personnel because the consequences of doing that 
were unknown. 

The dummy loads that were connected to the RJD were built for Lockheed Sanders to 
simulate orbiter thruster loads. They consist of a coil in series with a small resistive load. 
There are two simulated thruster loads, one of which models a vernier Reaction Control 
System (RCS) thruster, the other a primary RCS thruster. Each model has a separate load 
for the fuel solenoid and the oxidizer solenoid. These dummy loads were replaced with 
actual valves in test set 4 which is described in section 4.4. However, since only one direct 
acting valve was available, it was attached to the oxidizer side and a 25 Ohm power resistor 
was attached to the fuel side. This resistor was sized such that it would draw 
approximately the same amount of current as the dummy loads. If the resistor is not used, 
the fuel side appears as an open circuit and all of the associated switches indicate failure. 


PCI * 366 


RJD FACE PLATE SCHEMATIC 
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Figure 1 - Prototype 1 Test Configuration 


The 486 PC, which is labeled PC2 in Figure 1 , runs the Xilinx software, XACT 5.0. PC2 
is used to download new designs to the Xilinx chip on the RJD digital board. Once an 
LCA, logic cell array, file has been created in XACT, it is used to create a bit stream 
representation of that file. The bit stream file is then downloaded from the serial port of 
PC2 to the digital board via the Xilinx XChecker cable. When power is first applied to the 
digital board the Xilinx will read its program from either the PROM which resides on the 
board or the XChecker cable. In order for the Xilinx to read the program from the cable, 
switch number 4 on DIP switch bank U36 must be in the off position and the PROM must 
be removed from the board. Otherwise, the Xilinx chip will read the program from the 
PROM. The location of U36 and the PROM can be found on the RJD digital design 
schematics. 

The 386 PC, labeled PCI on Figure 1, runs the 1553 interface software used to send com- 
mands to the RJD. The 1553 card inside PCI is a DDC 65515. Since the graphical 
interface was developed with a different card, some minor software modifications were 
required. This difference in cards did not cause any problems once the modifications were 
implemented. 

The RJD face plate contains 48 LEDs to indicate whether each of the 16 switches is open, 
closed, or failed. There are also four LEDs that indicate whether or not the fuel and 
oxidizer solenoids have shorted. These LEDs were instrumental in demonstrating the 
device as well as providing output information to complete a majority of the tests that were 
run. 

A Tektronix 2440 digital oscilloscope was also used to collect data from the tests that were 
run. Switch outputs on the RJD analog board were probed to determine firing duration and 
skew times. 


2.2 Prototype 2 Configuration 

Figure 2 shows the test configuration for prototype 2. The main difference between Figure 
1 and Figure 2 is that Figure 2 has only one PC, PC2. Prototype 2 uses a Xilinx chip that 
is too advanced for the Controls Development Laboratory's Xilinx workstation. Therefore, 
the Xilinx program was always loaded from the PROMs (now four PROMs instead of one) 
because no changes could be made to the program. The 1553 65515 card was moved from 
PCI to PC2. 

Another change to the test configuration which is not apparent by looking at the figures is 
the power supply. The switch box, which allows the user to easily turn the power to the 
RJD on and off, always remains in the ON position. Prototype 2 requires that the voltage 
on the power supply be slowly increased to 28 Volts. If it is simply switched on, the 
system will lock up and will not accept commands from the 1553 interface. By powering 
up slowly, most of the switches will come up in a fault state. However, these states are 
reset when the graphical interface program is started. 

In both prototypes there were lines available to input pressure transducer signals. Since no 
pressure signals were simulated in any of the tests, these lines were ignored. In prototype 
2, however, a pressure transducer fault would occur if these lines were left floating. To 
eliminate this error the input signals were shorted to one of the switch outputs. 
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The last difference in the configurations is that the primary thruster load banks were 
returned to Lockheed Sanders after prototype 1 had been tested. Therefore, only the 
vernier thruster load bank was tested for prototype 2. 
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Figure 2 - Prototype 2 Test Configuration 


2.3 MIL- 1553 Interface 

The RJD incorporates a MIL- 1553 command and data interface. For both of the 
prototypes, this interface is mechanized with a single string 1553 transceiver configured as 
a bus slave unit. A production RJD would likely require redundancy in this area, since 
failure of the 1553 interface causes loss of the functionality of the entire driver. 

Use of the 1553 as the primary command and data interface for a critical component poses 
several unique challenges in the design and implementation of a flight control system. For 
an existing system such as the Shuttle orbiter, die challenge is one of integrating the digital 
interface within an existing mixed digital/analog system. An all digital system 
implementation poses problems of its own, some of which may be shared with the mixed 
system. 

For either application, that 1553 is a rigid master/slave arrangement can be a difficulty in a 
time critical flight control application. Typical of this is the case where the RJD, running 
autonomously, detects a jet failure. The RJD cannot report the failure or any related status 
words until such time as the bus master (most likely to be the flight control processor) polls 
it for the data. This and other difficulties can best be characterized as system integration 
issues. These include appropriately sizing both minimum and maximum bum durations 
and ensuring that the frequency response of the entire reaction control system does not 
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combine with any overall flight control system operating frequency or vehicle structural 
mode, thus avoiding signal aliasing or flight control instabilities. 

The 1553-related testing that we conducted as part of this effort was merely a cursory 
scratch at the surface of the above problems. This was necessitated by test and evaluation 
time constraints and resource limitations. Basic testing was accomplished to establish a 
qualitative feel for the impact of the 1553 interface on the overall RJD's performance. The 
result of this testing was that the 1553 does not of itself introduce any unacceptable or even 
perceptible latencies with respect to responses to fire commands. The bandwidth of the 
1553 interface as well as the entire RJD digital complement was deemed satisfactory in that 
the entire system's net resolution was sufficient to encompass the shortest bum durations 
that a physical thruster might be expected to respond to and the longest bum command that 
might be part of a propellant dump sequence. The 1553 interface exhibited acceptable 
repeatability of bum initiate timing and total bum durations. 
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3.0 Test Procedures and Results 


Four sets of tests were performed on both prototype 1 and prototype 2. This section 
summarizes the procedures followed when running the tests and the results of those tests. 
The results are given for both prototypes. If there was a discrepancy between prototype 1 
and prototype 2, it is noted in the relevant section. 


3.1 Basic Functionality Test Set 

A series of tests were run to verify the basic functionality of the RJD prototype and the 
results were compared to the specifications given in the Digital Design Report to verify the 
correctness. The tests in this section were performed only on the load banks. 

The functionality tests included firing the jets for various durations, firing the jets with 
various fuel/oxidizer skew times, flushing the fuel and oxidizer tanks, reading data from 
SRAM (Static Random Access Memory), and resetting the system. This verified that all 
functions worked properly before the direct acting valve or the pilot operated valve was 
connected to the system. With the exception of reading data from SRAM, the correctness 
of all operations was verified visually by watching the LEDs on the front panel of the 
prototype. Since the built in test function runs at too high a frequency to see on the LEDs, 
another feature was built into prototype 2 to slow the entire system down. This mode is 
used only for demonstration. To verify that the SRAM data collection was working 
properly, a sample of data was written to a file. The following paragraphs describe the 
results of this test set. 

Fire commands and fire duration settings were selected on the graphical interface and sent 
to the RJD via the 1553. The fire commands were executed successfully and changing the 
duration was visible on the LED front panel. This test was qualitative and actual 
measurements of firing durations were not done until test set 2. One problem arose during 
this test which was very repeatable. If consecutive fire commands were sent at a high rate, 
a 1553 error would occur. The error prevented any further communication with the RJD 
via the 1553 cable. Recovering from the error required quitting the graphical interface 
program and restarting it. This problem was not investigated to determine the exact cause 
of the 1553 bus error because of time constraints. This problem was associated with the 
second prototype and not the first. 

Fuel/oxidizer solenoid actuation skew times were verified in the same way that the firing 
times were verified. The test was qualitative and consisted of setting various skew times 
and watching the LEDs on the front panel to verify that the solenoids were activated at 
different times. Due to a problem with the interface program, the skew function did not 
work on the first prototype. Once a current version of the interface program was obtained, 
there was not another problem with the skew times in either prototype. 

The flush commands were also verified visually. The flush oxidizer and flush fuel 
commands are separate buttons on the graphical interface which toggle on and off. Both 
fuel and oxidizer flush commands executed correctly. However, the implementation was 
different between the first and second prototypes. The first prototype would allow fuel and 
oxidizer to flush at the same time. The second prototype would not allow one side to flush 
if the other side was already flushing unless it was toggled three or more times. 

To verify the SRAM data collection, the data was written to a file and plotted. The SRAM 
rendition of a solenoid current signature during a firing event was directly compared with 
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the signature as captured on an oscilloscope. The two signatures were found to overlay 
each other, verifying the proper operation of the SRAM loading and interrogation logic and 
indicating that any quantization errors introduced in the analog to digital conversion process 
were negligible. The second prototype had both the file writing and plotting functions built 
in, which was very useful. 

The purpose of the reset function was to reset any switch failures. If the switch was 
actually failed, it would immediately go back to the failed state once BIT was executed. 
During startup some of the switches come up in a failed state due to the rate at which power 
is applied to the system. This provided an easy way to verify the reset function worked 
properly, which it did. 

On the first prototype, all of the functionality tests were rerun after the program was down- 
loaded from the XChecker cable connected to the serial port of PC2 in the test setup. This 
verified that the program on the PROMs was the same as the Xilinx LCA program. It also 
verified our procedures for downloading a new program to the Xilinx chip. 


3.2 Firing Duration/Skew Test Set 

At the beginning of this test set current measurements were taken off the power supply to 
determine how much power the prototype was consuming. While the prototype was idle or 
running CBIT, it drew approximately 0.4 Amps. The power supply was set to 28.0 V, so 
the power consumption was 1 1.2 W. 

Power = 28.0 V * 0.4 A 
Power = 11.2 W 

During a firing, the current increased to approximately 1.6 Amps, which increased the 
power to 44.8 W. This is consistent with Figures 3 and 4 which show the fuel and 
oxidizer solenoid each drawing approximately 0.6 Amps. 

Power = 28.0 V * 1.6 A 
Power = 44.8 W 


The accuracy of the firing duration was tested for a range of values. This was performed 
by connecting a probe from the oscilloscope to the transistors on the analog board. There 
are 16 transistors on the analog board that correspond to the 16 switches in the RJD 
system. A voltage is seen on a particular transistor when that switch is closed, so the 
duration time was measured by monitoring the voltages on the transistors. The data was 
stored and read directly off the oscilloscope. 

During prototype 1 testing, duration errors of about 10% were reported. Later, it was 
determined that an incorrect signal was being monitored. Once that problem was solved, 
all tests on prototype 1 and prototype 2 showed that firing durations were accurate to within 
10 msec and the fuel and oxidizer solenoids were being activated at exactly the same time. 

Testing the fuel and oxidizer firing skews was performed by probing the transistors on the 
analog board - exactly the same way the firing duration tests were performed. However, 
the skew tests had the advantage of being able to verify the times with the data stored in 
SRAM. The data stored in SRAM is the voltage measured across a 1.0 Ohm resistor in 
series with the solenoid. That voltage is amplified by a factor of 3.148 before the data is 
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stored. Therefore, the current data was equal to the voltage values stored in SRAM divided 
by 3.148. Although the firing is stored in SRAM, the duration could not be verified 
because data could only be collected for the commanded firing duration. Consequently, the 
current drop was not 




captured in the data. Figures 3 and 4 show two skew time test cases. The firing duration 
for both of these plots is 0.2 seconds, but the plots do not verify that. Several skew values 
for oxidizer and fuel were tested and they were all accurate to within 1.0 msec. 
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One phenomena was uncovered while plotting the skew test data. Plots of the voltage data 
stored in SRAM showed a spike at the end of the firing. Lockheed Sanders advised that 
this was an artifact of the plotting package. The fact that there was not actually a spike was 
verified by checking the data on the oscilloscope. 


3.3 Failure Mode Test Set 


The main objective of this test set was to verify the rerouting algorithms in the RJD 
prototype in the event of switch failures. Figure 1 shows the numbering scheme for the 
switches on the RJD front panel as they will be referred to in this section. Any paths 
leading to the fuel and oxidizer solenoids will complete the circuit and allow those 
solenoids to be activated. Since there are 16 switches and 2 states for each switch (failed 
and not failed) there are 256 possible failure scenarios. This test set will not attempt to 
cover all cases. However, it will test all 8 possible fire paths (shown in Table 2) and the 
conditions where no fire paths are possible. 


Power Supply 



Figure 5 - RJD Prototype Switch Configuration 


As described in the RJD Digital Board Preliminary Design Document, when a firing is 
commanded, the highest priority fire path for the fuel and oxidizer solenoids is selected. 
Table 1 shows the switches in each fire path and their order of selection. This is the same 
specification that both prototypes were tested against. However, the procedures for testing 
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the two prototypes were different. All results were recorded by verifying visually which 
switches were open, closed, or failed as indicated by the LEDs on the front panel. 

The first prototype was tested by modifying the Xilinx Logic Control Array (LCA) file that 
contained the program for the Xilinx field programmable gate array (FPGA) chip and then 
downloading that new program to the digital board. Failures were hardcoded into the 
design to simulate a hard failure in one or more of the switches. However, downloading a 
new program required resetting the power to the RJD, so recovering from a failure within a 
test was not possible in this configuration. The failure scenarios that were tested are 
outlined in Table 2. 


Table 1 - Fire Path Description taken from the RJD Digital Board Preliminary Design 
Document. The order of fire path selection for the fuel solenoid is FPO, FP1, FP2, FP3 
and for the oxidizer solenoid the order is FP4, FP5, FP6, FP7. 


Fire Path 
# 

Path Description 

Switches in 
Path 

FPO 

Fuel PRIM 1/SEC 1 

1,2 

FP1 

Fuel PRIM 1/SEC 1 

3,4 

FP2 

Fuel PRIM 1/SEC 2/SEC_3 

5,14,13 

FP3 

Fuel PRIM 1/SEC 2/SEC 3 

7,16,15 

FP4 

Oxidizer PRIM 1/SEC 1 

5,6 

FP5 

Oxidizer PRIM_1/SEC_1 

7,8 

FP6 

Oxidizer 

PRIM_ 1/SEC_2/SEC_3 

1,11,12 

FP7 

Oxidizer 

PRIM_1/SEC_2/SEC_3 

3,9,10 


Table 2 - Failure Test Matrix 


Switch # 
--> 

1 

2 

3 

H 

5 

6 

H 

8 

9 

10 

11 

12 

13 

14 

15 

16 
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Prototype 2 tests used the same failure test matrix, but a different method of simulating fail- 
ures. This prototype had DIP switches on the digital board to select which switches to fail. 
Although this still did not create an actual hardware failure, it was more realistic than 
changing the software with certain failures and then running that same software to recover 
from those failures. The DIP switches did feed directly into the Xilinx chip to create 
failures, but one could switch them back and forth from failed to not failed without 
resetting the whole system. 

The second prototype also differed from the first in that once a failed switch was detected 
all other switches that were in a common fire path were set to the failed state. This changed 
the outcome of some of the tests. For example, in test #15, where switches #4, #6, #8 and 
#1 are failed, the first prototype would use both a fuel and an oxidizer cross-over path to 
complete a firing. There were no available paths for the second prototype for test #15. 
Since this was a change made to the design after the first prototype was delivered, both 
tests were successful in that they met the specifications in their respective design 
documents. 

All of the failure test results for prototype 1 and prototype 2 were as specified in the Digital 
Design Document. When a fire path was not operational because of a failure, the next 
highest priority fire path was selected. 


3.4 POV/DAV Current Signature Data Collection 

Some additional tests were performed on the direct acting valve (DAV) and the pilot 
operated valve (POV) to determine what effect different pressures had on the opening time 
of the valves. This was not a test of the RJD system, but a test to clarify some 
characteristics of the valves themselves. 

The DAV was provided by Marotta. They did not provide specific operating constraints, 
but did recommend attaching a thermocouple to the valve to monitor the temperature if a 
long series of short pulses was going to be used. The valve body temperatures should not 
exceed 48.9° C (120° F). No thermocouple was deemed necessary because the firing 
frequency required to heat the valve to 48.9° was never approached. ° 

Figure 6 is a graph of a representative firing of the DAV. The current signature is different 
than the load bank because there is a downward spike as the valve actually opens (the load 
bank is simply an inductive load with a small resistive load in series). The point at which 
the valve opens is marked on the plot 

Several test firings were run at various pressures. A sample of these runs are plotted 
together in Figure 7. Although no analysis was performed on the data acquired for this 
segment of the test, there is an obvious trend which was consistent throughout the testing. 
At higher pressures the valve takes longer to open, a result that is not unexpected in that it 
is consistent with the design of the valve. The graph in Figure 7 is an exploded view of the 
part of the firing in which the valve is opening, so that it is easier differentiate between 
different pressure settings. 

Another trend was noted during the testing. For a given pressure setting, the first valve 
opening in a sequence of firings tends to take longer than subsequent valve openings. The 
valve opening times seem to decrease until converging on a value. Figure 8 shows a 


12 



representative example of this phenomena. Although this trend did not always hold, it 
proved true for approximately 85% of the firing sequences. 

One problem with the data collection scheme in the RJD was that the first firing after startup 
was not stored in the SRAM. This is probably due to a logic error that could be corrected 
in the software. Therefore, the firing designated as "first" in Figure 8 is actually the second 
firing. It would be interesting to see whether the actual first firing followed this trend. 



Time (sec) 

Figure 6 - Current Trace of 0.2 Second Firing of DAV at Ambient Pressure 
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The Marquardt pilot operated valves were acquired from the power and propulsion division 
at the Johnson Space Center. Personnel from that division provided operating limits for 
those valves. Those limits consisted of a maximum fire duration of 1.0 second and a duty 
cycle of not more that one firing every 10 seconds. 

The pilot operated valve was also tested at different pressure settings. A representative 
current trace of a 0.2 second firing at ambient pressure is shown in Figure 9. The valve 
opening time is marked on that graph. The valve opening time for ambient pressure is 12 
msec. This is 8 times faster than the DAV opened. 

Current traces for the different pressure settings are shown in Figure 10. As expected, 
there was a tendency for the valve opening time to increase as pressure increased. This 
was also the case for the DAV which was shown in Figure 7. There was, however, one 
exception to that tendency. The opening time for the 200 psig case was shorter than the 
150 psig case. After rerunning the test, the results came out the same. The cause of this 
anomaly was not known at the time of this report. 

The other trend identified during the DAV testing was that for a given pressure setting, the 
first valve opening in a sequence of firings tends to take longer than subsequent valve 
openings. This was not the case for the POV. Current traces for 5 consecutive firings are 
shown in Figure 1 1 and they have almost exactly the same valve opening times. This 
repeatability is required for orbiter applications, so it was designed into the valve assembly. 



Figure 9 - Current Trace of 0.2 Second Firing of POV at Ambient Pressure 
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4.0 Failure Environment Analysis Tool Model 


4.1 General Description of FEAT 

FEAT, Failure Environment Analysis Tool, is a failure propagation software tool 
developed by Lockheed Engineering and Sciences Company (LESC) in Houston. It is 
comprised of several distinct software modules. The logic digraph models analyzed by 
FEAT are created in the Digraph Editor. The RJD model was done with FEAT version 3.2 
and Digraph Editor version 3.0 for the Macintosh. The RJD logic digraph is shown in 
Figure 13. A UNIX version of FEAT was available but was not used in this effort. 


Digraphs are built of "and" and "or" logic gates in what is referred to as "failure space", or 
in the environment of considering failure consequences rather than positive outcome 
events. FEAT models are created by choosing one undesirable end event and then mapping 
toward that event through the various system components. Other end events must be 
modeled through the use of additional FEAT models. FEAT is somewhat similar to Fault 
Tree Analysis, but is unique in that the program has multiple failure capability. This allows 
the user to set failures in order to predict events involving the set failure in combination 
with other failures. Faults can be propagated both forwards and backwards by either 
selecting a component as a source of failure for propagation forward, or as target from 
which to map the failures backwards that could cause the selection to fail. FEAT indicates 
when multiple faults are required to cause a failure by color coding those paths. 

Any Macintosh schematic saved in PICT format may be loaded into FEAT and matched to 
the logic digraph under consideration. The only requirement is that the schematic 
components be given a link name that matches the link name in the Microsoft Excel™ 
formatted input tables and that each portion of a component, including the link name, is 
grouped into one "block" in the drawing file. 

The schematic for the RJD is shown in Figure 13. This model has 46 "and" and "or" gates 
and highlights the redundant switching capability of the RJD. The model was developed 
under the assumption that the undesirable end event is that no jets fire. The loss of the 
power supply would cause this, as would loss of the controller. As the model shows, the 
switch redundancy is such that you must lose both paths directly to each valve as well as 
the crossover paths to lose fire capability on that valve. Failures that were not capable of 
propagation to disable a valve were not included. 


The FEAT program is useful for highlighting propagation paths at the system level. It 
could also be used as a presentation tool for illustrating redundancy, robustness, and 
system failure propagation protection. However, getting into lower than component-level 
details quickly becomes cumbersome for both the model constructor and the program. The 
running time of the program increases substantially as model complexity increases. It 
became apparent while creating the RJD model that concentrating on the functionality of the 
system leading to the valve failures was a better approach than trying to simulate exact 
hardware failures in die model. Thus, the power failure propagates through the switching 
network to fail the valves, even though power failure does not "fail" the switches per se. 
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Figure 12 - Reaction Jet Driver Digraph 
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Figure 13 - Reaction Jet Driver FEAT Schematic 


4.2 FEAT Inputs 

There are three Excel tables which are required inputs for this version of FEAT; one to de- 
scribe the components (called "comp.tbl"), one to describe the type of failures (flow 
failure, hardware failure, etc. - called "failure.tbl") and the failure mechanism (power fails 
off, etc.), and one to link the components with the types of failures they are susceptible to 
(called "comp.tbl"). The ".tbl" extension is necessary for FEAT to identify the tables. All 
three tables must reside in the same folder where the FEAT programs are located, in order 
for FEAT to utilize them for data input 
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The Excel tables below are part of the data tables used in the RJD FEAT model. They are 
illustrated here to illustrate how FEAT uses the three data tables to build digraph models. A 
portion of each excel file necessary for building a digraph is presented below. 


Table 3 - Component ' 

r able 

MNPWR 

MAIN POWER SOURCE 

PWR1 

MPWR 

DATAB 

1553 DATA BUS 

CNTR1 

DBUS 

SOVFU 

FUEL SOLENOID 

FUELS V 

VALV 

CROFO 

FUEL/OXIDIZER CROSSOVER 

FOCROSS 

XOVR 

SOVOX 

OXIDIZER SOLENOID 

OXSV 

VALV 


The first column in the component table is a five-letter mnemonic describing that 
component. FEAT uses this code name when creating failure descriptors for the 
components in the program. The second column is a brief description of the component. 
The third column must match the name of the component in the schematic, if there is one, 
for the schematic to successfully link to the digraph. The fourth column contains a four- 
letter descriptor of the type of component. For example, both the oxidizer and fuel 
solenoids have the same designator, which is "valv". This same coded descriptor is used 
in the Excel failure table. 


Table 4 - Failure Table 


FCLOS 

FAILS CLOSED 


VALV 

FNOIN 

FAILS WITH NO OUTPUT TO THE SYSTEM 


DLIN/XOVR/TRAN 

FNOPW 

FAILS WITH NO POWER OUTPUT 


MPWR 

FNOCM 

FAILS WITH NO COMMAND OUTPUT 


DBUS/DINT 

FNOUT 

FAILS WITH NO CURRENT OUTPUT 


ATDC/CTVS 


In the Excel failure table, the first column is a five-letter code for the failure one is 
describing. FEAT uses this when assigning a failure code to the components in the model. 
The second column is a description of what the failure is. The third column is a required 
column, but did not contain useful information for this model so it was be left blank. The 
fourth column has the component generic designators from the fourth column of the 
components table, such that a link can be made between the type of component it is and the 
type of failure it can sustain. 


Table 5 - Node Table 


F 

FLOW NODE 

H 

HARDWARE NODE 

C 

CREW NODE 

D 

DUMMY NODE 

T 

TEST NODE 


The last table is the node table. This is a two column table, containing whatever types of 
failure nodes one may wish to use in the model. Crew node might be for human error, and 
is thus not used in the RJD model. Dummy nodes may be necessary to show certain gate 
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structures due to program limitations. For example, only two inputs are allowed per "and" 
gate. The only nodes used in the RJD model are flow nodes and dummy nodes. 

A lot of the finesse required in the use of the FEAT program and interpretation of its results 
involves ensuring that the data in the Excel tables is correct. The failures must be correct 
for each component and the links between the components and which failures they can 
sustain must be appropriate and correct 
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5.0 Conclusions 


The first RJD prototype was tested so that feedback could be provided while the second 
prototype was being developed. It was also used as a demonstration tool. It served well in 
both capacities. The second prototype was tested to measure its performance. All of the 
functions advertised in the Digital Design Document were successfully completed. The 
firing and skew durations were measured with a digital oscilloscope and were within 10 
and 1 msec, respectively, of their commanded values for all test cases. Finally, an 
abundance of failure scenarios were tested and the prototype reacted to all of them as was 
described in the documentation. In addition to the success of the RJD tests, the concurrent 
design process was also successful. The process was supported by internet connectivity 
between Lockheed Sanders and LESC, which allowed for very quick transfers of data and 
updated versions of the 1553 graphical interface software which was under development 

The POV and the DAV testing was important in that the RJD system was proven to work 
with actual hardware. The data received from those tests will be instrumental in more 
clearly defining the characteristics and in studying the failure modes of the valves. 

The FEAT program is better suited for system level design verification and analysis rather 
than modeling component-level details. It could be used as a presentation tool for 
illustrating redundancy, robustness, or system failure propagation protection. 

Some work was still in progress at the end of this contract. An addition to the 
LabWindows program which provided the graphical interface to the RJD was not 
completed. This addition consisted of a GPIB interface from the digital oscilloscope to the 
PC. The oscilloscope is triggered by a fire command and collects the subsequent data. The 
data is then transferred back to the PC into a data file which would be compared to the 
SRAM data. Further analysis of the 1553 interface was also planned. The 1553 analysis 
work included measuring data transfer latencies, effects of multiple slaves connected to a 
single master, and general 1553 limitations. 
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Reaction Jet Driver Digital Board 
Preliminary Design Document 

Inna Gurevich/Tom Geocaris 


1.0 Scope 

This document contains the proposed design for the second iteration of Reaction Jet 
Driver (RJD) Digital Board Prototype ( a brief description of the Analog design is found at 
the end of this document). The RJD controller is a prototype system that interprets com- 
mands from a flight control system and energizes the Fuel and Oxidizer Solenoids to con- 
trol fuel and Oxidizer flow within the thrusters. The RJD has limited responsibility for 
health management, but is designed to support a Vehicle Health Management based Avi- 
onics architecture. 

This single jet system is intended as a precursor and a test-bed for a fully engineered sys- 
tem for initiating and monitoring jet firings for a wide variety of platforms. 

This RJD design document is subject to change per further design refinements. 

1.1 Document Overview 

2.0 Documents 

2.1 Government Documents 

Relevant Government Documents are included by reference in the Lockheed Documents 
specified below. 

2.2 Lockheed Documents 

The following documents form a part of this Design Document to the extent specified 
herein. In the event of conflict between the documents referenced and the contents of this 
document, the contents of this document shall be considered a superseding requirement. 

Lockheed Sanders, Inc., “Conceptual Design For the Reaction Jet Driver Prototype”. 
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3.0 Functional System Requirements 

3.1 Definition 

The RJD will energize the solenoids which control fuel and oxidizer valves. During a 
Built-In-Test (BIT) mode, the RJD will test for switch and solenoid failures and report on 
their status. At the receipt of a Fire command from the MIL-STD-1553 bus interface, RJD 
will energize the solenoids in a safe and timely fashion, and will record significant events. 

At the time of the power up, the RJD will initialize the MIL-STD-1553 bus interface and 
will download from the Xilinx PROM, resident on the prototype, the configuration data 
stream into the Xilinx Field Programmable Gate Array (FPGA) chip. At start up the FPGA 
chip will go into an Initial Built In Test (IBIT) mode and all of the threshold parameters, 
bum time duration and skew parameters will initialize to default values which shall be 
provided by the customer. The default values may be overwritten by loading different 
parameters via 1553 command. This capability will enable updates of these parameters to 
optimize jet performance. Please refer to Table 1 for the list of default re-programmable 


TABLE 1. Default Re-Programmable Parameters 


Parameter Description 

Parameter 
Default Value 

Resolution 

Bit Equivalent 
in Hex 

Fuel Bum Duration (16 bit) 

80 ms 

10 ms 

0008h 

Oxidizer Bum Duration (16 bit) 

80 ms 

10 ms 

0008h 

Fuel Skew Value (8 bit) 

00 ms 

01 ms 

OOOOh 

Oxidizer Skew Value (8 bit) 

00ms 

01 ms 

0000b 

Pressure Transducer Threshold value (8 bit) 


19.5 mV 

[32h 

Number Of Samples Count (16bit) 

| 

1 sample 

140h 


parameter values and Table 2 for the list of default constant parameter values. The data 


TABLE 2. Default Constant Parameters 


Parameter Description 

Parameter 
Default Value 

Resolution 

Bit 

Equivalent in 
Hex 

Switch Open Threshold Value (8 bit) 

1384 mV 

19.5 mV 

47h 

Switch Closed Threshold Value (8 bit) 

585 mV 

19.5 mV 

lEh 

Fuel Solenoid Short Threshold Value (8 bit) 


19.5 mV 

>FD 

Oxidizer Solenoid Short Threshold Value (8 bit) 


19.5 mV 

>FD 


will be read from the MIL-STD-1553 bus interface as it arrives and will be stored in the 
register internal to the FPGA chip. Upon request, status data stored in the FPGA will be 
made available to the 1553 for status words. Refer to the 1553 Commands table for the list 
of such status information, and to the Register Description section for the detailed descrip- 
tion of what information is contained in the status registers. IBIT test is completed after all 
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sixteen (16) switches of the Switching Network depicted in Figure 1 have been opened 



and tested for faults. If the switch did not open then a Fail Test and Switch Open Test bits 
will be set in the BIT Switch Test Register. The RJD Digital Board switches are numbered 
from 00 to 15 and in the Analog Board switches are numbered from 01 to 16. The IB IT 
test will take one (1) millisecond to perform. 

Once the IB IT is completed, the Continuous Built-In-Test (CBIT) is initiated. If there are 
no Fire or Flush commands RJD proceeds with CBIT. RJD goes into an Idle mode of oper- 
ation after four (4) iterations of CBIT if no Fire or Flush commands has been received 
unless it has been commanded to stay in CBIT via Run Continuous BIT Sequence 1553 
command. In which case RJD goes into Idle mode only if a Interrupt CBIT 1553 com- 
mand is received. RJD will stay in Idle mode of operation until it receives Fire, Rush Oxi- 
dizer, Rush Fuel, BIT Sequence or CBIT Sequence 1553 bus interface commands. Fire 
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will initiate a Fire mode, Flush Oxidizer/Fuel will initiate the Flush modes, the BIT 
Sequence will initiate one sequence of BIT which includes one ffilT and four CBITs in 
order to periodically check on condition of the switches, and CBIT Sequence will initiate 
one IBIT and continuous CBITs until an Interrupt CBIT 1553 command is received in 
order to check status of the switches for operator defined duration of time. If it is discov- 
ered that there are too many failed switches, RJD goes into Abort mode and reports this 
error (bit 0 of the BIT Error Status Register). 

A Fire or a Flush command can be accepted from MIL-STD-1553 bus interface at any 
time during CBIT, one (1) millisecond after it is initiated. It may take up to two (2) milli- 
seconds for a Fire or a Flush to start. This is due to the test sequence implemented by 
CBIT. For testing purpose the switches in the Switching Network are grouped into Switch 
Test Banks (STB). Refer to Figure 2 for the Switch Test Bank description. Each of the 



Switch Test Banks contain four (4) switches that are defined as Prim_l, Sec_l, Sec_2, 
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Sec_3 and are identified in this Figure. CBIT Mode section of this document describes the 
test sequence that is implemented in RJD. 

If Fire or Flush commands are received during the CBIT mode, RJD initiates IB IT in order 
to open the switches and then enables the appropriate Fire Paths which are determined by 
the switches without failures. During Fire mode RJD samples wave data a Sample-Count 
number of times at a four (4) kiloHertz rate, and monitors system for runtime failures. If a 
shorted solenoid is detected, RJD updates the BIT Error Status Register and goes into 
Abort mode and stays there until it is reset. The sampled wave data is stored in SRAM for 
later data retrieval. 

This RJD prototype will contain sixteen (16) Megabytes of RAM to store data for up to 
five thousand (5000) fire commands, assuming an average fire duration of eighty (80) mil- 
liseconds and assuming the number of samples is the length of fire duration divided by the 
sampling rate of 4KHz. The number of samples shall be provided via MIL- STD- 1553 bus 
interface and will be stored in the Number-Of-Samples register. Once the memory is filled, 
no more data will be recorded. However, this RJD prototype will provide an option of 
resetting the SRAM in which case the previously stored information will be overwritten. 
The memory address can be accessed via 1553, to help determine how much SRAM has 
already been filled. The SRAM address is twenty four (24) bits. 

Since the RJD fire latency, the time from receipt of Fire command to solenoid energizing 
must be within 4 ms, only IB IT will be executed before the acceptance of Fire command. 
The time required to run a complete CBIT is 15 millisecond and to run IB IT is lmilisec- 
ond. If the RJD were to be fired successively with a period between firings less then 16ms, 
switch failure of a switch-closed test may not be detected, since CBIT was not allowed 
time to complete. Consequently, the RJD may not fire due to an undetected failed switch 
which does not close. 

After completion of Fire or Flush modes of operation RJD goes back to IBIT in order to 
open up any switches that may have been closed and to provide an updated switch status. 
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Refer to Figure 3 for a complete RJD Controller State Diagram. In Figure 3, the FO_cmd 



refers to the Rush Oxidizer 1553 command, FF_cmd refers to the Rush Fuel 1553 com- 
mand, FO_done and FF_done refer to the Rush Oxidizer/Fuel done status. 
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3.2 Performance Characteristics 

The information in Table 3 will be assumed in the RJD Digital Board Design. It shows the 


TABLE 3. Register Resolutions 


Register 

Range 

Available 

Bit Resolution 

Bit Width 
Available 

Bit Width 
Required 

Fuel Burn Time 

0 to 655.35 sec 

10 ms 

16 

9 

Oxidizer Bum Tune 

0 to 655.35 sec 

10 ms 

16 

9 

Fuel Skew Time 

0 to 255 msec 


8 

7 

Oxidizer Skew Time 

0 to 255 msec 

1 ms 

8 

7 

Pressure Transducer Threshold 

0 to 5 V 

19.5mV 

8 

8 

Switch Open Threshold 

0 to 5 V 

19.5mV 

8 

8 

Switch Closed Threshold 

0 to 5 V 

19.5mV 

8 

8 

Number Of Samples per Fire 

0 to 65535 

1 sample 

16 

15 

Cumulative Bum Time 

0 to 4140 sec 

0.25 ms 

24 

22 


ranges and resolution of programmable parameters and system data. The resolution refers 
to what value does one bit represent in a register. For example to program the Oxidizer 
Bum Time to a value of 50 milliseconds, the value 5 would be written into the Oxidizer 
Bum Time register. The ranges in this table are based on the register bit widths not the 
actual ranges. For the Cumulative Bum Time, the resolution is specified as 0.25 ms (i.e. 4 
KHZ rate) instead of 0.25 us (i.e. 4 MHZ rate) because the Cumulative Bum Time is based 
on the Pressure Transducer data which is read from the A/D at the 4 KHZ rate. This may 
cause a.5msec resolution loss per fire. For the typical threshold, skew ranges and bum 
durations refer to Table 4 . 


TABLE 4. Typical Threshold/Burn Duration Resolutions 


Register 

Typical Ranges 

Bit Resolution 

Typical Bit Widths 

Fuel Bum Time 

0- 5*10*3 ms 

10 ms 

9 

Oxidizer Bum Time 

0 - 5*10 A 3 ms 

10 ms 

9 

Fuel Skew Time 

0- l*10 A 2ms 

01 ms 

7 

Oxidizer Skew Time 

0- 1*10*2 ms 

01 ms 

7 

Pressure Transducer Threshold 

0- 5*10*3 mV 

19.5mV 

8 

Switch Open Threshold 

0- 5*10*3 mV 

19.5mV 

8 

Switch Closed Threshold 

0 - 5*10*3 mV 

19.5mV 

8 

Number Of Samples per Fire 

0-21*10*3 

1 sample 

15 

Cumulative Bum Time 

0- 1*10*6 ms 

0.25 ms 

22 


3.3 IBIT Mode 

IB IT is an initial test sequence that is performed to verify continuity and readiness to oper- 
ate. IBIT in initiated at the system Start Up, after Fire or Flush Oxidizer/Fuel mode of 
operation has been completed, or after BIT Sequence or CBIT Sequence 1553 bus inter- 
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face commands have been received when RJD is in Idle mode of operation. During this 
mode all sixteen (16) switches are opened, switch-open device failures are detected and 
the BIT Switch Pass/Fail Test (SPFT) sixteen (16) bit status register is updated and alter- 
nate solutions of available Fire Paths are determined. The BIT Error Status Register is also 
updated at this time. If IBIT determines that there are no available Fire Paths due to failed 
devices, a CAN NOT FIRE Error Flag is set. 

The IBIT mode utilizes the BIT Switch Pass/Fail Test (SPFT), the BIT Switch Close/Open 
Test (SCOT), the BIT Error, the Mode Indicator, the Switch Open Threshold and the MIL- 
STD- 1553 bus interface Command Registers. The Register Description section of the spec 
contains detailed information on these registers. 

Refer to Figure 4 for the IBIT Flow Diagram where s[i] refers to the i* switch. SPFT[i] is 


C ''N 

l mode = ibit ) 



set High when i* switch fails the Pass/Fail Test and the SCOT[i] will be set Low since 
IBIT runs only the switch-open test. Each switch test consists of four (4) consecutive reads 
from the Analog/Digital converter to prevent false reading when noise persistence in the 
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system is three (3) micro-seconds or less. A switch failure resulting from two or more 
reads will constitute a total switch failure. 

If i 111 switch has been set High by a previous test then it is not tested any further and is left 
set as such in the BIT Switch Pass/Fail Test Register. The corresponding BIT Switch 
Open/Close Test Register bit is also left displaying the test that was running when the 
switch has failed. The switches are tested in the incremental order until all sixteen (16) 
have been tested. A Turn-On Delay interval of 512 microseconds must pass before the 
switch is tested and a three (3) microsecond interval must pass between each of four (4) 
switch samples. Since all of the switches are opened simultaneously the IB IT takes one (1) 
millisecond to perform. 

3.4 CBIT Mode 


CBIT is a continues test that checks for switch failure in the closed and open state and ver- 
ifies the switch path integrity. One CBIT test sequence consists of testing the Test Switch 
Banks (STB) in sequential order four (4) times, updating the Fire Path Status Register and 
disabling the corresponding solenoid energizing path. The individual switch test consists 
of four (4) consecutive reads from the Analog/Digital converter to prevent false reading 
when noise persistence in the system is three (3) micro-seconds or less. A switch failure 
resulting from one or more reads will constitute a switch-failed status. 


During CBIT, RJD tests for the Fuel and Oxidizer Solenoids open line failures. The Open 
Line Failure condition is suspected when switch failure of Prim_l and Sec_l switches in 
STBO and STB 1 or STB2 and STB3 is detected. When these conditions are detected, the 
FUEL SOLENOID OPEN LINE FAILURE (OR SWITCHES 0, 1,2 & 3 FAILED) and/or 
OXIDIZER SOLENOID OPEN LINE FAILURE (OR SWITCHES 4, 5, 6, & 7 FAILED) 
Error Flags are set in the BIT Error Status Register. This test sequence is illustrated in Fig- 
ure 5 where SPF[0:3] and SPF[4:7] indicate the status of the Switch Pass/Fail register for 
the appropriate switches. A set high bit in this register indicates that switch has failed the 
test 


The Fire and/or Flush commands can be accepted from MIL-STD-1553 bus interface at 
any time during the CBIT mode, one (1) millisecond after it is initiated. It may take up to 
two (2) milliseconds for a Fire or a Rush to start. This is due to the test sequence imple- 
mented by CBIT. 

Upon receipt of the Fire command the RJD calls the RJD Controller State and initiates an 
IB IT in order to open the switches that may have been closed during a switch test and then 
transitions into a requested mode and energizes the fuel and oxidizer solenoids for the 
duration that is stored in the Fuel Bum Time and Oxidation Bum Time Duration Registers 
with the skews that are stored in the Fuel Skew Time and Oxidation Skew Time Registers. 

Figure 6 illustrates the sequence of tests to check for a failed switches in the Switch Net- 
work. Test Switch Bank (0,1,10,11) in this figure refers to the Switch Test Bank (STB) 
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one. Refer to the CBIT Switch Test Banks Paths Table for reference. The i refers to a 
counter that indicates the CBIT iteration which is currently being tested. 

When a failure is detected, it is reported to the BIT Switch Pass/Fail Test Register and the 
Fire Path Status Register is updated. There are four (4) Fire Paths for each of the sole- 
noids. The same Fire Paths are valid for the Flush Fuel/Oxidizer operations as well. If one 
of the switches fails during the STB test, two of the valid Fire Paths are disabled. Refer to 
Table 5 for the list of disabled Fire Paths in case of a particular switch failure. The RJD 


TABLE 5. Disabled Fire Paths 


Failed Switch 

Fire Paths Disabled 

Switch #00 or Switch #01 or Switch #10 or Switch #11 

FP0 and FP6 

Switch #02 or Switch #03 or Switch #08 or Switch #09 

FPl and FP7 

Switch #04 or Switch #05 or Switch #12 or Switch #13 

FP2andFP4 

Switch #06 or Switch #07 or Switch #14 or Switch #15 

FP3 and FP 5 


shall be able to continue controlling the solenoids in the event of single failure per a 
Switch Test Bank. 

The CBIT mode utilizes the BIT Switch Pass/Fail Test (SPFT), the BIT Switch Close/ 
Open Test (SCOT), the BIT Error, the Mode Indicator, the Switch Open/Closed Thresh- 
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old, the MIL-STD-1553 bus interface Command, Fire Paths (FP) and Switch Test Bank 
(STB) Registers. The Register Description section of the spec contains detailed informa- 
tion on these registers. 

3.4.1 Switch Test Bank (STB) test 

A total of four (4) Switch Test Banks that are tested in CBIT mode of operation. The STB 
is a subset of CBIT. Refer to the CBIT Switch Test Bank Paths Table. The switches 0, 2, 4, 
and 6 are the primary switches, referred to as Prim_l within the Switch Bank. The 
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switches 1, 3, 5, and 7 are referred to as Sec_l within the Switch Bank. The switches 8, 
10, 13, 15 are referred to as Sec_2 within the Switch Bank, and the switches 9, 11, 12, 14 
are referred to as Sec_3 within the Switch Bank. A Prim_l switch within a Fire Path can 
be shared by two solenoids during Fire or Flush operating mode. Since the secondary 
switch path requires the use of the primary switch path it is best to test it in conjunction 
with the primary switch path. When testing a Switch Bank, the status of previous failures 
will be evaluated. If switch(es) in the Switch Bank had failed before, then CBIT proceeds 
with testing the next Switch Bank. If there were no previous failures then the Prim_l 
switch will be closed and tested first. If the Prim_l switch fails then the switch is opened 
for safety and failure is statused in the Switch Pass/Fail Test (SPF) Register by setting the 
SPFT Register bit High. The Switch Open/Close Test (SCOT) Register is also updated by 
setting the SCOT Register bit High to indicate switch closed test failure. If the Prim_l 
switch does not fail, then STB test proceeds with testing a Sec_2 switch. Refer to Figure 7 



Sec_2 switch Test 


FIGURE 7. Test Switch Bank: Close Test of Switch Prim_l 


for Close Switch Prim_l test sequence. 

If Prim_l switch did not fail the switch-close test, then it is kept closed and the crossover 
switches Sec_2 and Sec_3 are tested one at a time. If they fail then the SPFT and SCOT 
Registers are updated, the switches are marked as failed and STB test proceeds to testing 
the second main path Sec_l switch. However, before Sec_l switch can be tested, the 
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Prim_l need to be opened up to keep the equivalent resistance levels for all the switch 
tests. Refer to Figure 8 for Close/Open Switch Sec_2 and Sec_3 and open Prim_l test 
sequence. 


The last switch in the Switch Bank to be tested is Sec_l. Refer to Figure 9 for its test 



FIGURE 9. Close/Open Test: Switch Sec_l 


sequence. 

3.5 Fire Mode 

Fire Mode is initiated by a Fire command received from the MIL-STD-1553 bus interface. 
When Fire command is received RJD checks for available Fire Paths. If too many 
switches had failed during BIT, a CAN NOT FIRE or DEGRADED MODE Error Rags 
would have been set in the BIT Error and/or Mode Indicator Status Registers. If there are 
Fire Paths available, then Prim_l/Sec_l switch Fire Path is selected first. If that path is a 
failed path, then Prim_l/Sec_2/Sec_3 path is selected. For Fuel Solenoid the order of Fire 
Path selection is: FPO, FP1, FP2, FP3. For Oxidizer Solenoid the order of Fire Path selec- 
tion is: FP4, FP5, FP6, FP7. After the Fire command is accepted, the Prim_l switch is 
closed and the three concurrent processes of Managing Fuel Solenoid, Managing Oxidizer 
Solenoid and Collecting Data are started. After these three processes are completed, they 


Reaction Jet Driver Digital Board Preliminary Design Document December 23, 1994 


13 














Volume IE: Design Details 



Gose/Open Test: Switch sec_2 


Qosesec 2 
Wait 512us 


Open sec_2 
SPFT[sec_2] = 1 
SCOT[sec_2] = 1 


Switch sec 2 
failed. 


Open sec_2 
Wait 512us 


SPFTsec_2] = 1 
SCOT[sec_2] = 0 


Switch sec_2 
faded. 


Is switch 
sec 2 

_ open? _ 


Gose/Open Test: Switch sec_3 


Gose secJ3 
Wait 5 1 2us 


Open sec_3 
SPFT[sec_3] = 1 
SCOTfsec_3] = 1 



open Prim_l switch A 


itch sec_3 


Is switch 
sec_3 
closed? 


Open sec_3 
Wait 512us 



open Prim_l switch B 


Open prim_l 
Wait 512 us 


Open prim_l 
Wait 512 us 


Return To 
CBIT 


. SPFT[prim_l] = 1 
SCOT[prira_l] = 0 


, No 
'Switch prim_l 
failed. 


Is switch'"' 
prim I 


Is switch^ 
prim 1 

.open?/ 


No SPFTIprim_l] = 1 

Switch priml ** SCOT[prim_l] = 0 


Return To 
CBIT _ 


G os e/Open Test: Switch Sec_l 


FIGURE 8 . Test Switch Bank: Close/Open Test of Sec_2 /Sec_3 & Open Test of Prim_l Switches 
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are synchronized and Prim_l switch is opened. Refer to Figure 10 for the Fire Process 



Flow. 

The Fire mode utilizes the BIT Error Status, Mode Indicator Status, Fuel/Oxidizer Bum 
Time Duration, Fuel/Oxidizer Skew Time Duration, Cumulative Bum Time, Pressure 
Solenoid Threshold, Number of Samples, MIL-STD-1553 bus interface Command and 
Fire Paths Registers. The Register Description section of the spec contains detailed infor- 
mation on these registers. 
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3.5.1 Manage Fuel/Oxidizer Solenoid 

At the time of the Fire command the Fuel/Oxidizer Bum Durations and Skew values are 
loaded into their respective registers. The Fuel/Oxidizer Fire Paths are enabled after their 
skew values expire and they are disabled after their respective bum durations expire. Refer 
to Figure 1 1 for the Manage Fuel/Oxidizer Solenoids Process. 



These are concurrent processes that are 
synchronized when they end , however, their 
run time length can differ. 


The Prim_l switch was opened prior to this stage, 
and will be closed after it 



FIGURE 11. Manage Fuel/Oxidizer Solenoids Process 


Reaction Jet Driver Digital Board Preliminary Design DocumentDecember 23, 1994 




Volume El: Design Details 
3.5.2 Collect Data 

RJD will store single mission significant information. The Fuel Solenoid, Oxidizer Sole- 
noid and Pressure Transducer Waveforms will be stored in the on board SRAM and will be 
available upon request via 1553 at completion of a mission. The Cumulative Bum Dura- 
tion, the SRAM Data Length, the Solenoid Shorted Failure and Pressure Transducer Fail- 
ures will be stored in the FPGA registers and will be available upon request via 1553 
during a mission. 

The data waveforms from the A/D converter will be sampled at the rate of four (4) kilo- 
hertz and thus have a resolution of ,25ms. The number of samples to be taken will be pro- 
vided via 1553 and loaded into the RJD Number of Samples Register. 

RJD will track the bum time duration during a Fire based on Pressure Transducer Wave- 
form readings. The fire duration is considered the time duration that the Pressure Trans- 
ducer reading is above the specified threshold. These bum durations will be accumulated 
over all the Fires during a mission and stored in the Cumulative Bum Time Duration Reg- 
ister. The number of samples requested should be large enough to cover the bum duration 
period. If number of samples does not cover the whole bum duration, only those samples 
will be stored in SRAM, but the bum duration time will continue to be tacked and added to 
the Cumulative Bum Time Duration. 

If the Pressure Transducer Waveform persists for over four (4) milliseconds after comple- 
tion of firing then a transducer failure is suspected and a Pressure Transducer Failure error 
bit in the BIT Error Status Register is set. The same failure condition is suspected if no 
Pressure Transducer Waveform is detected for over four (4) milliseconds after the start of 
the fire.In the case of such failure the RJD runs an EBIT in order to update the status of 
switch failures and then goes into an Abort mode. When in Abort mode, RJD does not 
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accept any further commands and expected the operator to reset it. Refer to Figure 12 for 

10/31 all wave data thoould 
be sampled 4 time* before 

Duration Ot Hre flagging an efTOT 



FIGURE 12. Pressure Transducer Failure Condition Diagram 


the Pressure Transducer Failure condition diagram. 


Another type of error that can be detected during Fire mode is the Fuel/Oxidizer Short con- 
dition. Oxidizer/Fuel Solenoid Shorted Failure is flagged when a high solenoid current 
exists for a period of one (1) millisecond. A one (1) millisecond persistence is required 
because back EMF spikes may appear across the differential amplifier that measure the 
solenoid current. The eight (8) bit A/D converter should return a value of 255 when a high 
current is present, however inaccurate reference voltages, noise and other factors may 
reduce the stability and predictability of the measured current. Thus the lower bit of die AJ 
D value will be ignored and an FE hexadecimal value will be used as the short detection 
threshold. If required, further reduction of low order bits will be incorporated. Upon detec- 
tion of Solenoid Shorted condition, the RJD fire sequence is aborted, IB IT and then Abort 
modes are initiated. 

The SRAM data will be accessible for reading form the 1553 bus. 


Refer to Figures 13 , and 14 Data Collection Processes. 


Reaction Jet Driver Digital Board Preliminary Design Document December 23, 1994 


18 


Volume ID: Design Details 



sample_cnt = numbcr_of_xamples 
memory[address] = LSB(numb«f_of_^arnplc*) 
address = address + 1 

memory[addressJ 3 = MSB (number_o (^samples) 
address = address + 1 
current_burn_time_cnt = 0 
fuel_soleno id_sbort_cnt = 0 
oxidixer_iolenoid_short_cnt = 0 
burn_pres5iire_ofT_cnl = 0 
burn_pressure_OD_cDt = 0 


fuel = The fuel A/D measurement 


^ Is the ^ 
sample_cnt > 0 


Store Wave Data 

memory! address} = fuel 
address = address + 1 


^ Is the ^ 
k fuel >= OxFE 


fuel_solenoid_short_CDt = 0 


Is thc\. 

fuel solenoid_ s>Vs ^ Yes Abort RJD Fire 

short cut = 3 P Set error status fuel solenoid_short 


fuel_solenoid_short_cot = fueI_*olenoid_short_cnt + 1 


Return To 
FIRE? 


Sample Wave Data 


oxidizer = The fuel A/D measurement 


^ Is the ' 

sample.cnt > 0 


Store Wave Data 

memory [address] = oxidizer 
address = address + 1 


Is the^^^ 
oxidizer >= OxFE 


oxidzier_»olenoid_short cnt = 0 


lithe 

-nTiHi 2 ct, solenoid Ycs ^ Abort RJD Fire 

'\short_.cnl = 3 Set error status oxidzier _solenoid_short 


oxidzier_solenoid_short_cnt a oxidizer _solenoid_short_cnt + 1 



Return To 
FIRE? 


FIGURE 13. Data CoOection A 
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Sample Wave Data y 

pressure = The fuel A/D measurement 


ipH jent > 0 


Store Wave Data 

memaryfaddress] = pressure 
address = address + 1 


^ i \re the" 

, fuel and oxidizer 
solenoids de-energized, Le^ 
'^^done 


^ Ls the pressure >* ^ 
burn_pressure_threshold 

tmij)res«ire_5f_cnt = 15 


Set error status pressure gauge has 
failed 


bum_pressure_off_cnt = burn_pressure_ofif_cnt + 1 


Are the 

■""T fuel and oxidizer 
solenoids energized, i.e., 

Is RJD firing? 


^ ^ Is the pressure < 
burn_pressure_threshold and is 
■^burn _pressure_on_cnt = 15^" 


Set error status pressure gauge has 
failed 


burp_jpressure_on_cnt = burn_pressure_on_cnl + 1 




^Is the pressure >= ^ 
^urn_pressure_threshoM 


Increment burn time 

current_burn_time_cnt = current_burn_time_cnt + 1 


.^Ts the pressure >= 
&urn_pressureJhreshold ^ 
and the pressure guage is good 
.or the number of samples > 0 


cum_burn_time * cu m_burn_ti me + cuirent_buni_tinK_cnt 


Return To 



FIGURE 14. Data Collection B 
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3.6 Flush Mode 


When the FLUSH FUEL/OXIDIZER (TOGGLE ON) command is received from the 
MIL-STD-1553 interface, one of the available Fuel/Oxidizer Switch Fire Paths is closed 
to allow the selected solenoids to energize. The Solenoid stays energized until a receipt of 
FLUSH FUEL/OXIDIZER (TOGGLE OFF) command coming from the MIL-STD-1553 
interface. The FLUSH FUEL and FLUSH OXIDIZER command must be mutually exclu- 
sive to prevent accidental RJD firing. Refer to Figure 15 for the Flush Fuel and Flush Oxi- 
dizer process. 

3.7 Clock Rate 

RJD Digital Board will contain two (2) crystal oscillators. A twelve (12) MHZ oscillator 
for MIL-STD-1553 bus interface and a four (4) MHZ oscillator for the Xilinx FPGA con- 
troller chip. 

For demonstration purposes, the FPGA will be enabled to run at a slow clock rate of 
roughly 2KHz. 

3.8 Setup/Hold Inputs and Clock outputs 

A/D interface - to be defined. 

3.9 1553 interface 

The MIL-STD-1553 interface will be realized using the BUS-65153 chip supplied by 
DDC. This chip will be used to implement the protocol described in Table 5. 
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Flush Fuel 


Is there a N 
solenoid 
energize path?^ 


Set error status 
cannot flush 
fuel. 


Return to 
CBIT 


Energize 

Solenoid 


command = toggle flush^ 
fuel ofi^^ 


De-energize 

Solenoid 


Return to 
CBIT 


Flush Oxidizer 


Is there a ^ 
solenoid 
energize path?. 


Set error status 
cannot flush 
oxidizer. 


Return to 
CBIT 



command = toggle flu 
\ oxidizer c 


De-energize 

Solenoid 


Return to 
CBIT 


Note: Solenoid kept energized until user sends the flush off command. 

FIGURE 15. Flush Fuel/Oxidizer Process 
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3.9.1 Command Bus 

Table 6, where the T/-R is the transmit/receive which is the addrl2 bit of the address bus. 


TABLE 6. 1553 Commands 


1553 Sub- 

Address 

ADDR[11:07] 

Function if T/~R 
(ADDR[12])=0 

Function if T/-R (ADDR[12])=1 

00000 

Mode Command??? 

Mode Command??? 

0 1111 

Reset 


0000 1 

Load Number of Samples 
(16 bit) 

Send BIT Switch Pass/Fail Test 
Status Register (16 bit) 

000 10 

Load Fuel Bum Duration 
(16 bit) 

Send BIT Switch Open/Close Test 
Status Register (16 bit) 

000 1 1 

Load Oxidizer Bum Dura- 
tion (16 bit) 

Send BIT Error & Mode Indicator 
Status Register (16 bit) 

00 1 00 

Load Fuel Skew Value 
(8 bit) 

Read Back the Cumulative Bum 
Time MSBs [23:16] 

00101 

Load Oxidizer Skew Value 
(8 bit) 

Read Back the Cumulative Bum 
Tune LSBs [15:00] 

00 110 

Load Pressure Transducer 
Threshold value (8 bit) 

Read Back SRAM Data Length 
MSBs [23:16] 

0 0111 


Read Back SRAM Data Length 
LSBs [15:00] 

0 1000 

Load Switch Open Threshold 
Value (8 bit) 

Start SRAM Wave Data Transfer 

0 100 1 

Load Switch Closed Thresh- 
old Value (8 bit) 

Read Back the SRAM Wave Data 
(8 bit) 

01010 

Flush Oxidizer (Toggle ON) 

Flush Oxidizer (Toggle OFF) 

01011 

Flush Fuel (Toggle ON) 

Flush Fuel (Toggle OFF) 

0 1100 

Run one BIT sequence 


0 110 1 

Run continuous BIT 
sequence 

Demo Clock Speed 

0 1 1 10 

Interrupt CBIT 

Fire 

10000 

Reset SRAM 



The data is received when addr[12]=0 and it is transmitted to the 1553 bus when 
addr[12]=l. 
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3.10 SRAM interface 

3.10.1 Wave Data Storage and Retrieval 

The fuel solenoid current, oxidizer solenoid current and pressure transducer waveforms 
are stored in SRAM. These waveforms are sampled at a frequency of 4KHz. The amount 
of samples taken during a RJD fire is user definable (see the register description for “Num- 
ber of Samples”). Sampling begins upon receipt of a fire command. This means wave- 
forms are sampled during the skew phase of the fire sequence. The amount of data that can 
be stored is dependent upon how much SRAM is installed, the number of samples taken 
per RJD firing, and how many RJD firings occur on a mission. For example if the average 
bum durations were 133 ms and 8 megabytes of SRAM was installed, a total of 5000 fire 
waveforms could be stored. 

Due to the limited Direct Memory Access (DMA) capability of the 1553 Bus interface and 
in order to provide efficient storage of data, wave data is stored and retrieved from SRAM 
in the following format illustrated in Table 7 . Data N corresponds to the N number of 


TABLE 7. SRAM Memory Allocation Scheme (Byte Oriented) 


¥iii 

K'Wt 

m 

Kyy 

M 


Wave: 

Wave" 


gjjg| 

Wave 

Daia v 

4m 

§§ 

Fire 

1 

0 

# of sam- 
ples 

# of sam- 
ples 

Fuel 

Oxid 

izer 

Press 

ure 

Fuel 

Oxid 

izer 

Press 

ure 



Fire 

2 

3 * # of 
samples 
+ 2 

# of sam- 
ples 

# of sam- 
ples 

Fuel 

Oxid 

izer 

Press 

ure 

Fuel 

Oxid 

izer 

Press 

ure 



■ 


# of sam- 
ples 

# of sam- 
ples 

Fuel 




Oxid 

izer 

Press 

ure 


.... 

Fire 

K 











.... 


samples taken. Fire K corresponds to the K number of Fire commands received by RJD. 
The Table also shows that data storage begins at address zero in SRAM. The data stored at 
this location corresponds to the first firing of the RJD during a mission. Data from subse- 
quent firings is stored in sequential order. The first two bytes of a wave data define how 
many samples were taken during a RJD firing. These two bytes form a 16 bit number 
NUMBER OF SAMPLES (NOS) which is used as a pointer to the next block of wave 
data. Since three types of data are stored (oxidizer, fuel and pressure), the NOS must be 
multiplied by three. 

3.10.2 Data Interleaving 

The oxidizer, fuel and pressure waveform data is interleaved, as shown in Table 7. It is the 
responsibility of the user to de-interleave this data. 
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3.10.3 SRAM Address Counter 


Because the Number of Samples is programmable and the number of times an RJD is fired 
during a mission is not know in advance, the amount to data stored in SRAM is unpredict- 
able. The SRAM Address Counter can be read via the 1553 bus interface to determine the 
amount of data stored in the SRAM. 

3.10.4 Data Transfer (1553) 

Wave data is transferred via the 1553 Bus interface at the request of a user. Because the 
1553 can send only 64 words (128 bytes) per command request, the user must request 
multiple transfers. The protocol for a transfer is outlined in Figure 16. 



FIGURE 16. SRAM Transfer Protocol 


3.11 Switch Control interface 

The switch control bus (sw[16:01]_cntrl) will be sources by Xilinx and fed to the A/D via 
the P4 connector. Refer to the Table 16 for specific pinout. 
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3.12 LED driver interface 

RJD will contain an LED display indicating the pass/fail status of the switch, the current 
open/closed test status and the oxidizer/fuel solenoid status. The RJD will allow switch, 
solenoid, and pressure transducer faults to be set for test purposes by means of setting the 
on-board DIP switches. However, once a fault has been introduced it remains in the sys- 
tem until the board is reset. 

3.13 Test points 

The P2 connector will serve as a test point connector and will contain the 
1553_data[ 15:00] bus, 1553_subaddr[04:00] bus, 1553 control bus, sram_data[07:00] bus, 
sram_addr[23:00] bus, sram control bus and xilinxjo bus which is reserved for future use. 
Refer to Table 14 for specific pinout. 

3.13.1 Data Format 

To be discussed. 

3.13.2 Register Description 

• BIT Switch Pass/Fail Test 16 bit status register contains the Pass/Fail information of the 
16 switches. Bit 0 indicates switch number 1, and bit 15 indicates switch number 16. 
Bit set High indicates a Fail condition and a bit set Low indicates Pass condition. Refer 
to Table 8. 

• BIT Switch Close/Open Test 16 bit status register indicates whether the switch was 
shorted or opened when it has passed or failed. Bit 0 indicates switch 1, and bit 15 indi- 
cates switch 16. Bit set High indicates a Short condition and a bit set Low indicates an 
Open condition. Refer to Table 8. 


TABLE 8. BIT Switch Test Register 


BIT Pass/Fail Test 16 bit status register 

BIT Close/Open 16 bit status register 

bit#=Low => Pass Test 

bit#=Low =>Switch Open Test 

bit#=High => Fail Test 

bit#=High =>S witch Close Test 


Reaction Jet Driver Digital Board Preliminary Design Document December 23, 1994 


26 










Volume IE: Design Details 


• BIT error 8 bit status register contains the BIT Hard/Soft failure information. Bit set 
High indicates the occurrence of specified error condition. Refer to Table 9 for bit iden- 

TABLE 9. BIT Error Status Register 


Bit 

Number 

Error Condition Flag 

Bit 0 = High 

Can not fire (No Switch Path available or too many fets bad) 

Bit 1 = High 

Fuel Solenoid Open Line Failure (or switches 0, 1,2 &3 failed) 

Bit 2 = High 

Oxidizer Solenoid Open Line Failure (or switches 4, 5, 6, &7 failed) 

Bit 3 = High 

Fuel Solenoid Shorted Failure (During Fire) 

Bit 4 = High 

Oxidizer Solenoid Shorted Failure (During Fire) 

Bit 5= High 

Pressure Transducer Failure 

Bit 6 = High 

SRAM full 

Bit 7 = High 

Catastrophic Error (l0/31 fire/flush occurs due to switch failures detected in BIT-can *t prevent/ stop) 


tification. This bus takes up the 8 LSBs of the error status register data bus. 


• Mode Indicator 8 bit Status Register contains the mode of RJD operation information. 
Bit set High indicates the occurrence of the specified mode. Refer to Table 10 for bit 

TABLE 10. Mode Indicator Status Register 


Bit Number 

Mode of Operation 

Bit 8 = High 

Degraded Mode Flag Register 

Bit 9 = High 

Are in IBIT Mode of Operation 

Bit 10 = High 

Are in CBIT Mode of Operation 

Bit 11 =High 

Are in Fire Mode of Operation 

Bit 12 = High 

Are in Flush Fuel Mode of Operation 

Bit 13 = High 

Are in Rush Oxidizer Mode of Operation 

Bit 14 = High 

Are in Idle Mode of Operation 

Bit 15 = High 

Are in Abort Mode of Operation 


identification. This bus takes up the 8 MSBs of the error status register data bus. 


• Fuel Bum Time duration register is a 16 bit register containing the time parameter for 
the bum duration of fuel solenoid. 

• Oxidation Bum Time duration register is a 16 bit register containing the time parameter 
for the bum duration of oxidizer solenoid. 

• Fuel Skew Time duration register is an 8 bit register containing the time parameter for 
the skew duration value that needs to pass before enable the burning of the fuel sole- 
noid. 
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• Oxidation Skew Tune duration register is an 8 bit register containing the time parame- 
ter for the skew duration value that needs to pass before enable the burning of the oxi- 
dation solenoid. 

• Pressure transducer solenoid Cumulative Bum lime register is a 24 bit register contain- 
ing the total bum time duration over all the performed bums during a mission. This 
information is requested by 1553 command 

• Pressure transducer solenoid threshold 8 bit register 

• Switch open threshold 8 bit register 

• Switch closed threshold 8 bit register 

• Fuel solenoid short detection threshold 8 bit register (hardwire?) 

• Oxidizer solenoid short detection threshold 8 bit register (hardwire?) 

• Number Of Samples 16 bit register holds the value of the number of samples of a wave- 
form to be received from the A/D per current firing. This information is received via 
1553 chip. 

• MIL-STD-1553 bus interface Command Latch 16 bit Register contains the sub- 
addresses ADDR[12:07] coming from the 1553. 

• Fire Paths 8 bit Register contains the information of which switch paths are valid dur- 
ing the fire command. Refer to the Table 1 1 , for the list of Fire Path Register status bits 


TABLE 11. Fire Path Status Register 


Fire Path (FP) 

Switches 

FPO 

Switches: #00 and #01 

FP1 

Switches: #02 and #03 

FP2 

Switches: #04 and #12 and #13 

FP3 

Switches: #06 and #14 and #15 

FP4 

Switches: #04 and #05 

FP5 

Switches: #06 and #07 

FP6 

Switches: #00 and #10 and #1 1 

FP7 

Switches: #02 and #08 and #09 


and the list of switches associated with each path. If at least one of the switches in the 
path has failed then the FP Register bit is set high and that path becomes invalid. The 
fire paths 0 thru 3 are for the Fuel Solenoid and the fire paths 4 thru 7 are for the Oxi- 
dizer Solenoid. 
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• Switch Test Bank Register contains the information on the CBIT switch test sequence 
which is listed in the Table 12. 


TABLE 12. CBIT Switch Test Bank Paths 


Switch Test Bank (STB) 

Switches 

STBO 

Switches: #00, #01, #10, #11 

STB1 

Switches: #02, #03, #08, #09 

STB2 

Switches: #04, #05, #12, #13 

STB3 

Switches: #06, #07, #14, #15 


3.13.3 Counters 

• Fuel Bum Time duration loadable 16 bit down counter 

• Oxidation Bum Time duration loadable 16 bit down counter 

• Fuel Skew Time loadable 8 bit down counter 

• Oxidizer Skew Time loadable 8 bit down counter 

• Pressure Bum Time duration of the current Firing 16 bit up counter (with terminal 
count or reset &enable) 

• Switch on/off delay 12 bit counter {for the 512us switch delay} 

• Number Of Samples 16 bit up-counter counts up to the received number of samples 
when sampling the waveforms 

• SRAM Address Generator 24 bit counter will feed the SRAM Address Decode to gen- 
erate addressing for storing the Number-of -Samples, Oxidizer Solenoid, Fuel Solenoid 
and Pressure waveforms. This count will also be fed back to 1553 as 3 words, upon a 
request from 1553 at the end of the mission, indicating how much SRAM has been 
filled. This feature will help user to determine how much data needs to be read back 
from the SRAM. 

• A/D Address Generator 4 bit counter will feed the A/D Address Decode to generate 
addressing for BIT 

• A/D Address Generator 4 bit counter will feed the A/D Address Decode to generate 
addressing for Wave data 

• Read Back SRAM DMA 24 bit counter generates the SRAM addresses when 1553 
requests the SRAM data 

3.13.4 Comparators 

• Fuel Bum Time duration 16 bit comparator compares the current Fuel Bum Time to the 
Fuel Bum Time duration parameter 

• Oxidation Bum Time duration 16 bit comparator compares the current Oxidizer Bum 
Time to the Oxidizer Bum Time duration parameter 

• Fuel Skew Time 16 bit comparator 
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• Oxidizer Skew Time 16 bit comparator 

• Pressure Start Bum Time 8 bit greater then comparator compares the current waveform 
to the Pressure start/stop burning threshold 

• Pressure Stop Bum Time 8 bit less then comparator compares the current waveform to 
the Pressure start/stop burning threshold 

3.13.5 Adders 

• Pressure Bum Time total duration time over 5000 bums 32 bit adder 

3.13.6 Decoders 

• SRAM Address Decode {expect to have 3 of 3-to-8 decoders} 

• A/D Address Decode 

• 1553 Address/Control Decode 

• 1553 Command Word Decode 

3.13.7 Muxes 

• 16 bit 6: 1 mux to feed the 1553 multiplexed data out 

• 24 bit 2: 1 Muxes for SRAM data Read Back cycle 

3.13.8 State Machines 

4.0 Physical Characteristic 

4.1 Module Form Factor 

A 6U VME card. 

4.2 Power 

The RJD Digital Board will be supplied with a +5Vdc and -15Vdc via the P4 connector. 
The power requirements are TBD. 

4.3 Layout 

Refer to Figure 17 for the RJD Digital Board. 
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FIGURE 17. RJD Digital Board Layout 
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4.4 Pin I/O 

Four (4) VME connectors will be mounted onto the RJD Digital Board. Connector PI is 
the MIL-STD-1553 bus interface connector. See Table 13 for the PI pinout. 


TABLE 13. PI CONNECTOR (1553 BUS INTERFACE CONNECTOR) 


PIN# 
ROW A 

PIN# 

ROWB 

PIN# 
ROW C 

ROW A 

SIGNAL 

MNEMONIC 

ROWB 

SIGNAL 

MNEMONIC 

ROW C 

SIGNAL 

MNEMONIC 

12 

44 

76 



COAX1 

13 

45 

77 




14 

46 

78 




15 

47 

79 



GND 

16 

48 

80 




17 

49 

81 




18 

50 

82 



COAX2 
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Connector P2 is the Test Point Connector. See Table 14 for the P2 pinout. Connector P3 is 

TABLE 14. P2 CONNECTOR (TEST POINT CONNECTOR) 


PEN# PIN# 
ROW ROW 



ROW A SIGNAL 
MNEMONIC 

ROW B SIGNAL 
MNEMONIC 

GND 

-1553.WRT 

12MHZCLOCK 

** UNDEF ** 

1553_DATA0 

** UNDEF ** 

1553_DATA1 

** UNDEF ** 

1553.DATA2 

GND 

1553_DATA3 

SYSCLK 

1553_DATA4 

SRAMJDATAO 

1553_DATA5 

SRAM_DATA1 

1553.DATA6 

SRAM_DATA2 

1553_DATA7 

SRAM_DATA3 

1553_DATA8 

SRAM_DATA4 


1553_DATA9 


1553_DATA10 


1553_DATA11 


1553_DATA12 


1553_DATA13 


1553_DATA14 


1553_DATA15 


12MHZCLOCK 


1553_LSB_MSB 


1553_DAT.CMD 


1 553_SUB ADDRO 


1553_SUBADDR1 


1553_SUBADDR2 


1 553_SUB ADDR3 


1553_SUBADDR4 


SRAM_DATA5 


MNEMONIC 


SRAM_ADDR16 


SRAM_ADDR17 


SRAM_ADDR18 


SRAM_ADDR19 


SRAM_ADDR20 


SRAM_ADDR2 1 


SRAM_ADDR22 


SRAM_ADDR23 


XILINXCLOCK 


-SRAM.WE 


-SRAM_OE 


SRAM_DATA6 

xhjnx_io_o 

SRAM_DATA7 

XILINXJO.l 

SRAM.ADDRO 

XILINX_IO_2 

SRAM_ADDR1 

XILINX_IO_3 

SRAM_ADDR2 

XILINX_IO_4 

SRAM_ADDR3 

XILINX_IO_5 

SRAM_ADDR4 

XILINX_IO_6 

SRAM _ADDR5 

XILINX_IO_7 

SRAM _ADDR6 

XILINX_IO_8 

SRAM_ADDR7 

XILINX_IO_9 

GND 

XILINX_IO_10 

XILINXCLOCK 

XILINXJO.ll 

SRAM _ADDR8 

XILINX_IO_12 

SRAM _ADDR9 

XILINX_IO_13 


60 

92 

1553_TRANS_RCV 

SRAM.ADDR11 

Not Available 

61 

93 

-1553.REQ 

SRAM.ADDR12 

Not Available 

62 

94 

~1553_GRT 

SRAM.ADDR13 

Not Available 

63 

95 

-1553_ACK 

SRAM.ADDR14 

Not Available 

64 

96 

-1553.CS 

SRAM.ADDR15 

Not Available 
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the LED display and A/D Connector. See Table 15 for the P3 Connector pinout. Connector 
TABLE 15. P3 CONNECTOR (LED CONNECTOR) 


PIN# 

ROW 

A 

PIN# 

ROW 

B 

PIN# 

ROW 

C 

1 

33 

65 

2 

34 

66 

3 

35 

67 

4 

36 

68 

5 

37 

69 

6 

38 

70 

7 

39 

71 

8 

40 

72 

9 

41 

73 

10 

42 

74 

11 

43 

75 

12 

44 

76 

13 

45 

77 

14 

46 

78 

15 

47 

79 

16 

48 

80 

17 

49 

81 

18 

50 

82 

19 

51 

83 

20 

52 

84 

21 

53 

85 

22 

54 

86 

23 

55 

87 

24 

56 

88 

25 

57 

89 

26 

58 

90 

27 

59 

91 

28 

60 

92 

29 

61 

93 

30 

62 

94 


63 

95 


64 

96 



VDD 


LED_SW7_STATUS 


LED_SW7_CLOSED 


LED_SW7_OPEN 


VDD 


LED_SW8_STATUS 


LED_SW8_CLOSED 


LED_SW8_OPEN 


VDD 


LED SW5_STATUS 


ROW B SIGNAL 
MNEMONIC 


ROW C SIGNAL 
MNEMONIC 




VDD 


LED_SW10_STATUS 


LED_SW10_CLOSED 


LED_SW10_OPEN 


VDD 


LED_SW12_STATUS 


LED_SW12_CLOSED 


LED_S W 1 2_OPEN 


VDD 


LED_SW9_STATUS 


LED_SW9_CLOSED 


LED_SW9_OPEN 


VDD 


LED_SW11_STATUS 


LED_SW1 l_CLOSED LED_FUEL_NORM 


LED_SWll_OPEN 


VDD 


LED_SW15_STATUS 


LED_FUEL_SHORT 

VDD 


LED SW2_STATUS 


LED_S W1 5_CLOSED LED_SW2_CLOSED 


LED_SW15_OPEN 


VDD 


LED_SW13_STATUS 


LED_SW2_OPEN 


VDD 


LED.SWl .STATUS 


LED.SW13.CLOSED LED.SWl .CLOSED 


LED.SW5.CLOSED LED.SWl 3.0PEN 


LED.SW5.OPEN 


VDD 


LED.SW6.STATUS 


LED.SW6.CLOSED 


LED.SW6.OPEN 


VDD 


LED.OX.NORM 


LED.OX.SHORT LED.SW14.OPEN 


VDD 


LED SW16.STATUS 


LED.SWl.OPEN 


VDD 


LED SW4.STATUS 


LED.SW16.CLOSED I LED.SW4.CLOSED 


LED.SWl 6.0PEN 


VDD 


LED SW14 STATUS 


LED.SW4.OPEN 


VDD 


LED SW3 STATUS 


LED SW14 CLOSED LED SW3 CLOSED 
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P4 is connected to the RJD Analog Board and hooks up to the A/D converter. See Table 16 
for the P4 Connector pinout. 


TABLE 16. P4 CONNECTOR (DIGITAL TO ANALOG BOARD) 



ROWA 

SIGNAL 

MNEMONIC 


~BIT1_RD 


-BITIJNT 


~BIT1_CS 


BIT1_RDY* 


BIT_ADDR0 


BIT_ADDR1 


BIT_ADDR2 


-WAVE.RD 


~WAVE_INT 


-WAVE_CS 


WAVE_RDY* 


WAVE_ADDRO 


WAVE.ADDRl 


WAVE_ADDR2 


ROWS 

SIGNAL 

MNEMONIC 



~BIT2_RD 


~BIT2_INT 


~BIT2_CS 


WAVE_DATAO 


WAVE.DATA1 


WAVE_DATA2 


WAVE_DATA3 


WAVE_DATA4 


ROW C 

SIGNAL 

MNEMONIC 


BIT_DATA0 


BIT_DATA1 


Brr_DATA2 


BIT_DATA3 


BIT_DATA4 


BIT_DATA5 


BIT_DATA6 




SW7_CNTRL 


SW8_CNTRL 


SW2_CNTRL 
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TABLE 16. P4 CONNECTOR (DIGITAL TO ANALOG BOARD) 


PIN 

PIN 

PIN 

ROW A 

ROWS 

ROW C 

# 

RO 

# 

RO 

# 

RO 

SIGNAL 

SIGNAL 

SIGNAL 

WA 

WB 

WC 

MNEMONIC 

MNEMONIC 

MNEMONIC 

30 

62 

94 




31 

63 

95 

SW4.CNTRL 



32 

64 

96 





* wired, but is not used in current version 


The P2 test connector is broken out into five 20 pin HP connectors. Refer to Table 17. Pins 


TABLE 17. P2 connector break-out into P9,P10,P11,P12, P13 


P2 

P9 

P2 

P10 

P2 

Pll 

P2 

P12 

P2 

P13 

PIN 

PIN 

PIN 

PIN 

PIN 

PIN 

PIN 

PIN 

PIN 

PIN 

# 

# 

# 

# 

# 

# 

# 

# 

# 

# 

1 

20 

19 

20 

EM 

20 

55 

20 

73 

20 

2 

3 

20 

3 

EM 


56 

3 

74 

3 

3 

19 

21 

19 

39 

19 

EM 

19 

75 

EM 

4 

18 

22 

18 

40 

18 

| 

18 

76 

tm 

5 

IBH 

23 

17 

41 

17 

59 

EM 

77 

17 

6 

KB 

24 

16 

42 

16 

60 

KB 

78 

16 

7 

I 

25 

15 

43 

15 


kb 

79 

KB 

8 

14 

26 

14 

44 

14 

62 

14 


tm 


IB 

27 

13 

45 

EM 

63 

13 

■ 

13 

Efl 

1 

28 

12 

46 

EM 

64 

12 

82 

12 

11 

11 

29 

11 

47 

11 

65 

11 

83 

11 

12 

10 

30 

10 

48 

10 

66 

10 

84 

10 

13 

9 

31 

9 

49 

9 

67 

9 

85 

9 

14 

8 

32 

8 

50 

8 

68 

8 

86 

8 

15 

7 

33 

7 

51 

7 

69 

7 

87 

7 

16 

6 

34 

6 

52 

6 

70 

6 

88 

6 

17 

5 

35 

5 

53 

5 

71 

5 

89 

5 

18 

4 

36 

4 

54 

4 

72 

4 

90 

4 


9 1 through 96 are not connected. 
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5.0 List of Acronyms 


CBIT - Continuous Built In Test 
CLB - Configurable Logic Block 
FP - Fire Path 

FPGA - Field Programmable Gate Array 

GUI - Graphical User Interface 

IBIT - Initial Built In Test 

RJD - Reaction Jet Driver 

SCOT - Switch Close/Open Test 

SPFT - Switch Pass/Fail Test 

STB - Switch Test Bank 


6.0 Operating Information and Instructions 

6.1 FPGA Hardware 

The RJD Digital board usses an XC4025-6 PG299 Xilinx FPGA. It is a 299 pin package- 
containing 1024 Configurable Logic Blocks (CLBs) . Four XC17128PD8C serial configu- 
ration PROMs are required for one XC4025 chip which contains 422,168 configuration 
bits. 

6.2 FPGA Software and files 

Xilinx schematic was implemented on Powerview V.5.1.2 using Viewdraw. The Xilinx 
V5.0 unified library must be used for designs targeting Xilinx V5.0 Software. The 
XC4025 die and package files must be included with the Xilinx V5.0 software. The total 
number of occupied CLBs is 801 out of the available 1024 CLBs, this represents 78 % 
capacity for the routed .lea file. The delivered files on the disks are : RJDV2.LCA, RJD- 
V2.BIT and RJDV2.MCS. The .lea file is a fully routed xilinx file, .bit file is for down- 
loading and .mcs is file used for programming the proms. 

(On the Sun these files are : >/wv/rjd_v2/ijd_xil_v2.* and /wv/rid_v2 delivered/rid x- 
il_v2.*) 
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6.3 GUI Software and files 

The following files are needed for Graphical User Interface (GUI): 

RJDV2.C, RJDV2.H, RJDV2.EXE, RJDV2.UIR, 

PLOT.C, PLOT.H, PLOT.EXE, PLOT.UIR. 

To run the software a Microsoft C compiler is required. 

(On the Sun these files are:>/wv/rjd_v2_delivered/*. + ) 

6.4 RJD Digital Board List of Files 

The RJD Digital Board files consist of board layout files and board schematic files named 
RJD_DIGITAL.* 

(On the Sun these files are:>/wv/rjd_v2_delivered/rjd_digital.*) 
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ANALOG SECTION 


The analog board is comprised of four sections: Power Switching Circuitry, Switch Built- 
In-Test (BIT) Circuitry, Solenoid-End-Of-Useful-Life (SEOUL) Circuitry, Pressure Trans- 
ducer Monitoring Circuitry, and the Analog-to-Digital Converter (ADC) Circuitry. 

Power S witching Circuitry 

The basic function of the reaction jet controller is to place the +28 volt supply onto the jet 
solenoids to energize them fully. The fully energized solenoids open the fuel and oxidizer 
valves allowing them to flow which in turn fires the jet. Placing a supply voltage onto a 
load is referred to as a high-side power switching configuration. To achieve this, a power- 
switching device in combination with a high-side driver circuit is required. The device 
selected for this task was the 

IR6220 device from International Rectifier. The IR6220 is a MOSFET device and high- 
side driver combined into a single package and can withstand inductive kick-back spikes 
as large as 72 volts. One of our design constraints was to allow as much of this kick-back 
voltage as possible to speed the closing of the solenoid-controlled valve. In general, most 
high-side driver circuits cannot withstand any negative kick-back voltages and request 
that a reverse-biased Schottky diode be placed across the load to clamp the kickback. By 
using the IR6220, large kickback voltages can be allowed without circuit damage. As a 
safety precaution, a 50 volt zener was placed across the load to create an upper bound on 
the size of the kick-back voltage 

The sixteen IR6220 switching devices were configured in an elaborate tree configuration 
to improve redundancy. As shown in the figure, there are two main solenoid energi zin g 
paths combined in parallel in line with each of the two solenoids in a single reaction jet. If 
a fault occurs in any one of these devices, usually a shorted device, the associated device 
in series with the failed one can be set to the open position isolating the faulted device. 

The solenoid can then continue to be controlled via the parallel path. 

In addition, there may be additional faults, possibly in the digital section, causing an 
inability to energize the solenoid via one of the main paths. To circumvent this fault condi- 
tion, cross-over switches are used to enable the analog card to energize both solenoids 
from a single working main path. The combination of main and cross-over paths yields a 
quad redundancy situation for energizing either solenoid. 


Switch Built-I n-Test (BIT) Circuitry 

This circuitry is set up to interrogate the health of each of the aforementioned power 
switching devices. In a normal scenario, each of the four switches in both of the main 
energizing paths should have approximately half the supply voltage across the switch. 
Operational amplifiers configured as differential amplifiers measure this voltage and send 
it to the ADC to be digitized and passed on to the controller for comparison with expected 
values. If the amplifier measures a voltage that is too low, then the switch has shorted and 
has failed the “switch open” test. In turn, each of these switches will then be turned on, 
measured and then turned off again. In this case the differential amplifier should measure a 
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low voltage indicative of the low impedance of a switch turned on. If this voltage is too 
large, then the switch will be considered as blown open and as having failed the “switch 
closed” test. Having passed both these tests, a switch will be considered as fully opera- 
tional. 

Similarly, each of the cross-over switches can be tested for the “switch open” and “switch 
closed” tests. Any switch flagged as failed will cause the appropriate workaround algo- 
rithms to be computed in the RJD controller for continued operation of the reaction jet. 

Solenoid End-Of-Useful-Life (SEOUL! Circuitry 

It had been reported to us that by examining the energizing current waveform for the sole- 
noid one could determine certain artifacts in the waveform that would denote an impend- 
ing solenoid failure. The best way to examine this current waveform is to place a small 
resistor in series with the solenoid under test and then monitoring the voltage across the 
resistor differentially. This differential voltage is then a direct representation of the current 
entering the solenoid. As with the BIT circuitry, operational amplifiers configured as dif- 
ferential amplifiers were used to monitor the voltage across a one ohm resistor in series 
with the solenoids. This voltage was then passed through an eight pole anti-aliasing filter 
before being sent to the ADC to be digitized. This digitized information was then passed to 
the RJD controller for analysis and storage in SRAM for later statistical computations. 

Pressure Transducer Mo nitoring Circuitry 

The pressure transducer provides feedback information as a confirmation that a reaction 
jet has fired. The transducer signal is presented to the reaction jet circuitry as a differential 
voltage 0-5 volts. As with the other signals in the analog board, this signal is received dif- 
ferentially and passed through an anti-aliasing filter and then on to the ADC for digitizing, 
and then on to the RJD controller for comparison to a threshold for verification of a jet fir- 
ing. This digitized waveform will also be stored for later statistical analysis. 

Analog-tQ-Didtal Converter (ADC) Circuitry 

As discussed in the aforementioned sections, all the transducer, BIT, and SEOUL signals 
are digitized in the ADC’s. Three ADC’s were needed to handle the large number of sig- 
nals to be converted. The Analog Devices AD7828 was selected as the converter since it 
was internally equipped with its own 8-to-l MUX to further simplify the circuitry 
required. Each AD7828 required its own control and address lines for proper operation. 
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Solenoid Fuel Valve Study 

Peter Dingus, SPCOT, Lockheed Sanders 


1.0 Introduction: 

We have developed a model for the POV, Pilot Operated (propellent) Valve, in an 
effort to assess the statistics of the various failure modes of the valves. The model also 
gives some physical insight into the relationship between the measured characteristics of 
the valves during testing, and the underlying mechanisms that produce those characteris- 
tics. In developing a valve model we have tried to use existing data sets so that we could 
tune the model to actually resembling real valves. In this way we can have some confi- 
dence that the underlying physical basis of the model reflects the actual valve, and that 
subsequent determinations in the movement of measured characteristics will correlate 
well with actual valve histories. 



Figure 1) CT trace and Hall sensor (White Sands) 

There are two types of valve data available. One consist of a trace produced by 
Hall Effect sensors attached to the valve. The idea is to measure the change in the mag- 
netic field produced by energizing the valve solenoid coil as the valve actuators move 
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through the magnetic field. The subsequent trace of Hall sensor output voltage vs time, 
clearly shows the opening of the main stage valve when mainstage pressure is applied as 
in actual operation. One the other hand, another measurement that reflects the operation of 
the valve is just the current vs time trace, C-T trace, associated with energizing the valve 
solenoid. This method of test has the advantage that it is completely unintrusive, it 
requires no additional measurement devices or sensors, and could serve as the basis of an 
on-line valve diagnostic each time the valve is energized. 

Measurements have been made using the C-T characteristic as a diagnostic in 
valve performance. Typically, the information that one wants about valve operation can be 
listed as follows: 

a) pilot opening time. 

b) pilot opening stroke. 

c) mainstage opening time. 

d) mainstage opening stroke. 

The pilot information, parts (a) and (b) are clearly reflected in the valve C-T characteristic, 
while the mainstage characteristics are less pronounced. Since it is ultimately the main- 
stage characteristics that are of the greatest interest for the proper functioning of the valve, 
one must assure that the C-T characteristic can supply information corresponding to parts 
(c) and (d) of the list above. After all, correct operation of the pilot stage does not guaran- 
tee correct operation of the mainstage. The C-T trace data has been taken on POV valves 
and has been correlated to the output of an accelerometer attached to the valve casing. The 
accelerometer develops a signal as the result of physical vibrations of the casing due to the 
shock of various valve actuators stopping against their stroke constraints. This then shows 
the time associated with various valve actuators and can be superimposed on the C-T char- 
acteristic to try to correlate various features on the C-T trace with actuator movement. Fig- 
ure (1) shows one such plot. One can see two large signals developed by the 
accelerometers. One corresponding to the dip of the first lobe in the C-T characteristic and 
the second is associated with a small dip on the flat-top of the C-T trace. Both of these dips 
indicate the stopping of the movement of armatures that open the two stages of the valve. 
The first dip is associated with the end of the pilot stroke and the second with the end of 
the mainstage stroke. 


2.0 Qualitative POV Valve Operation: 


A diagram of a POV valve is shown in figures (2) and (3). Figure (2) shows the 
valve in the closed position, i.e. before energizing the solenoid. In this position there is an 
air gap in both the mainstage stroke and armature at the top of the valve. Here we use air 
gap to mean a space occupied in the magnetic circuit of the solenoid which is not filled 
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Thruster Valve 

□ Ups re am pressure 
■ Downsream pressure 


Operation 

Propellant 

Inlet 



Thruster valve is closed. 


Figure (2) POV valve closed 


Thruster Valve 

□ Ups team pressu* 

■1 Do sms ream pressure 


Operation 

Propellant 

Inlet 



Pressure difference actuates main piston 
to open position. 


Figure (3) POV valve with main stage open 
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with high permeability ferromagnetic material and the top of the valve is defined to be that 
end of the valve cylinder which is opposite the fuel/oxidizer outlet. The mainstage poppet 
and pilot seat at the outlet end of the valve is in contact with main stage seat, there is no air 
gap here in the valve closed position. The inductance, L, of the overall valve system as 
seen from the coil terminals is a function of these are gaps. As one energizes the coil, the 
upper part of the pilot armature moves to close the upper gap. This increases the induc- 
tance which produces the first dip in the C-T trace. 


_ f dL _dL 
dl dt dt 

■ST— t OC 

dt L L 


As £ increases decreases. Such a large dip occurs because the £ is relatively 

large owing to the size of the gap involve and the u r of the magnetic material relative to 
the closed path of the entire magnetic circuit, 1. We find that: 

AL GX m 
L * + 

Where G is the gap size, 1 is the length of the closed magnetic field circuit, and % m is the 
magnetic susceptibility. Thus for typical values like l~.2m, G~0.002m, and x m -1000, we 

get £-100%. During the pilot’s motion, it transmits a force through flexures and a spring 

to the main stage armature and has opened the pilot valve. A pressure differential of about 
34psid, due to the opening of the pilot valve, develops between the front and back of the 
main stage poppet and forces open the mainstage valve. This in turn opens an air gap 
between the mainstage poppet and seat, reducing the inductance seen at the coil terminals. 
In this case, however, the change in L manifests itself in a shortening of the current rise- 
time, time constant, t = | . In this case ¥ increase with -£ . Therefore for a properly 
opening main stage we should see a smaller rise-time between the pilot induced dip in the 
C-T trace and the time at which I reaches its final height, i Final = Y, Thus, in principle, we 

should be able to get all of the information necessary, as enumerated in the introduction to 
monitor the functioning of the POV valve from the C-T trace. 
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3.0 The Model: 


Pilot Armature 


SP2 


Coil 

Main stage 
Armature 



Figure (4) Model 


The model articulates a simpler mechanical topology than that seen in the actual 
valve drawings, but tries to retain the basic features of the valve that create the features 
seen in the C-T trace. The simple model simulates the initial pilot-armature gap at the top 
of the valve by a piston with a flat top that moves on a shaft through the coil. It is coupled 
via a spring SP2 to a lower piston which initially has no gap. The upper piston is kept open 
by spring SP1. When the coil is energized the magnetic energy in the pilot armature gap 
(the upper piston) closes the upper gap producing the first lobe and dip in the current trace. 
This then compresses spring SP2 and starts to force the main stage (lower piston) open. As 
soon as the main stage starts to open a pressure-force is applied to open the main stage 

gap, which speeds up the final current time constant, x. The details of the model are given 
below. 


One can calculate the magnetic field strength, H, in the gaps by integrating the 
field around the magnetic circuit containing the current responsible for creating the field: 




mr 

i^(Gi-Si)-* 2 + M(G 1 -* 1 )+* 2 ) 1 
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where g l , g 2 are the coordinates of the two tops representing the pilot armature and main 
stage armatures respectively, and Gj is the pilot armature maximum gap opening. This is 
shown in figure (4). The energies contained in the gaps due to the magnetic field are: 

*.-t *)«;* 

Gu 

v 2 = 

where a, 2 is the surface area appropriate to contain the magnetic flux in the gap having 
made the assumption that the fields in the gaps are uniform. The force associated with 

changing the energy in the gap by changing the dimensions of the gap is F = The 

. . m dg' 

resulting equations of motion for the two position coordinates are: 

^ m ^££ 1 * Kvi, . f r 

dt 2 2rn p (l + X m (&+g 2 ) ) 2 m P m p (81 82 + 8o) -^ p 


2 


\i Q A 2 k 


dt 2 2 m m( l + X m (&+g 2 ) ) 2 


+ l~ g 2 + 8o) + 


fr 


m m 


( c p+ 


8 2 ) 


m 


m 


where k m - ^w 2 / 2 and k p , c p are constants which determine the initial force on the m ain 
stage piston due to the fuel/oxidizer pressure and k ap(l2) are the two spring constants. The 
coordinates g 12 are the two piston displacements and 4 = c rll , where g, is the full gap 
opening of the pilot armature. / r(1 2) are the frictional forces. 

The inductance, as seen from the leads of the coil, can be written as 

L = kmL - 

ll + X m (A+g 2 )] 
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where k mL = ^ r n 0 iV 2 A . A is the effective area of the magnetic circuit which links the coil 

windings and is related to the gap areas. Finally the differential equation for the current in 
terms of these parameters and relations is: 


dl 

dt 


V- 


XJ 


U + X m (A + g 2 ) ] 


/ 3g l _3g 2 ' 

dt dt j 


- RI 


These equations can be solved simultaneously for a self-consistent solution in the follow- 
ing way: 


3 *! 

Tt 


2 

^_£i 

dt 2 


_ dgi dx 3 _ dI 

d* dt ~dt 


dt dt dt ~ d 2 


The solution to diese equations will give us the C-T trace for the model with all of the sup- 
porting mechanics of the valve. We can then tune the model as a function of the various 
mechanical parameters such as: the areas of the magnetic gaps a, 2 , the lengths of the 

overall magnetic circuit “1”, the pressure constants Cp , k p , the spring constants s Pl 2 , the 
masses of the various armatures m pm , and the friction terms. We can using, a least squares 
procedure, fit the model C-T trace to that of data taken on POV valves. Using a tuned 
model will then allow us to vary critical parameters by a known amount and get statistical 
information on the movement of features we can extract from the actual valve C-T charac- 
teristic. These statistical results will allow us to make a quantitative assessment on the 
functional state of a valve under test. 


4.0 The Fit 

We were able to get test data from LESC, Kennedy, and White Sands. We selected 
the White Sands POV current trace data to tune the model. The fit was performed using a 
Simplex fitting program to step through iterations of a least squares function of the data 
and model. We used the White Sands data because we were assured that pressure had been 
applied to the main stage valve giving both pilot and main stage strokes the full range of 
movement. In actual operation, in a rocket thruster, the POV valve requires a delta pres- 
sure between the fuel inlet and outlet of 34psid - 53psid to open the main stage poppet. 
The movement of the main stage poppet is reflected in the rise time between the pilot 
induced current dip and the final current plateau of the CT trace. In all six parameters of 
the model were varied to achieve a fit: the masses of the pilot and mainstage armatures, 
m p.m ’ s P f2n 8 constants, k tp(l 2 ) ! the relative permeability of the armature/case material, \i r ; 
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and Che ratio */«, . which sets the scale of the main stage poppet delta pressure. The pilot and main 
stage strokes were set to 0.2cm and 0.5cm respectively. 


. ^ ata was divided into 32 bins, and sampled at lOKHz. The digitizer was eight bits. Eight 
bits yields an error per sample point of * 0.00195 amps, where we have normalized the scale such that the 

, C ^ nt ! S lamp ' S ™ e diere are about 1 1 points per bin this gives a x 2 / (df) = 2.7 for the fit. This 

not yet sufficiently good, however, there are more degrees of freedom in the fit. The fit results can be 
seen in Figure 5 on page 8 along with the main stage and pilot strokes. 



Figure 5) Fit to model, resulting strokes 


5.0 The Analysis: 

Once the model was tuned, we ran several files of events containing three different cases We 
were to y White Sands that the basic failure mode of the valves that they tested was fuel-oxidizer 

C !?!t r bl M Cked °[ interfered with A e motion of the valve. We therefore ran the valve 

tel ?n e T Vafl K 6 Pll °! f° ke ’ main Sta ^ e stroke > and varied the pilot motion with a friction 
. In each case the standard deviation on random gaussian distribution was set at 5% of the nominal 
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value. In the case of the friction term, it was determined from the model that the nominal force corre- 
sponding to the pilot armature acceleration is 2.1 Nts, thus the frictional force was varied so that 5% 
of this value was varied on a gaussian distribution about a nominal of 0.2Nts. We ran 1500 events and 
picked various features for the resulting CT trace. We chose to examine the resulting deviations in the 
time position of the first current lobe, the time deviations in the current dip due to the pilot stopping, 
the nse fime as measured between the current dip and the final current flat-top, and the current height 
of the first lobe. We expect the variations in the pilot stroke to be manifest in gaussian deviations of 
all of these features except for the rise time of the current flat-top. We also expect deviations in the 

main stage stroke to result in gaussian deviations in the current flat-top rise time. These can be seen in 
Figures 6 and 7 on pages 9 and 10. 

The frictional term, on the other hand, which affects the motion of the pilot manifests a gauss- 
ian deviation m the first current lobe position and heights. The effect on the flat-top rise time of a 5% 
deviation in the mam stage stroke is gaussian and shows a fit standard deviation of 0.7%. However a 
5% variation about a 10% frictional force results in an almost uniform distribution with a standard 

eviation m the flat-top rise time of about 2%. The measured variations for the various cases is tabu- 
lated m tables 1, 2, and 3 on page 11. 


First Lob© 



msec 


Main tr 



msec 


Pilot Dip 



Height First Lobe 



Figure 6) Pilot Stroke Variance 
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Figure 7) Variance due to Main Stage Stroke 
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Feature 

Mean 

Sigma 

% Change 1 

First Lobe 

0.0143 

0.0001 


Pilot Dip 

0.0172 

0.0005 

2.9% 

Main Rise Time 



— 

First Lobe Height 

0.521 

0.0189 

3.6% 


Table 1) Variance from Pilot Stroke 


Feature 

Mean 

Sigma 

% Change 

First Lobe 

0.0143 

0.0001 

0.7% 

Pilot Dip 


— 


Main Rise Time 




First Lobe Height 

0.5178 | 

0.0019 

0.37% 


Table 2) Variance from friction term 


Feature 

Mean 

Sigma 

% Change 

Main Rise Time 

0.0140 

0.0001 

0.7% 


Table 3) Variance from Main Stage Stroke 
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6.0 Conclusions: 

We have shown that we can extract all of the information from a POV valve CT trace 
necessary in determining its functional state in a nonintrusive way. Typical deviations in 
the four extracted features from nominal values tend to be smaller than the deviations that 
caused them by from 20-85%. The conclusion we draw from this is that differences in 
valves themselves due to manufacturing process may preclude an set of absolute nominal 
feature values. In looking at data from several good valves we have seen deviations of the 
order of those produced by 5% variations in the valve parameters that we have varied to 
access sensitivity to various failure modes. However, these failure mode variations are 
well defined and do offer a diagnostic handle. We can envision two different scenarios in 
which this information might serve as the basis of an on line diagnostic. First, each valve 
could be tested as par of its commissioning procedure and its nominal feature valves 
recorded. Later variations could be established with respect to the specific nominal values 
of that particular valve. A failure analysis could have been performed using statistics 
based on deviations relative to valve specific norms. Second, if we can improve the 

x/(df) of our model fit, we could use the variations in %/{df) between fits made of model 
parameters initially, at commissioning, and those made as an on-line diagnostic. 
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